0

I am the manager of a small team of software engineers.

I am looking for arguments in favor of automatic, mandatory code formatting.

For me it is natural, it goes with the Quality Assurance process and I do not question it too much ; commit cannot be accepted in our Python software if it does not passes through black. Many projects work the same.

But my lead developer is against this kind of formatting and I would like to have more arguments if someone can help :)

closed as primarily opinion-based by gnat, Jörg W Mittag, Robbie Dee, 17 of 26, Bart van Ingen Schenau May 17 at 13:36

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    @RobbieDee the formatting I am talking about is automatic, it takes no time on developers – mguijarr May 17 at 11:56
  • 3
    Some flexibility on code formatting can be useful for expressiveness or to emphasise relations. It can be useful to have principles that are only deviated from with good reason, but I would think there is no good general argument for applying all formatting by rule and without exception. Almost every formatting principle has degenerate cases that would benefit from exceptions, and the ill-will (whether expressed or not) created by rigid enforcement will almost certainly exceed the benefits to the code-reader of a standardised format. – Steve May 17 at 11:56
  • 1
    @Steve Agreed - we have used a similar tool in the past with very little perceivable benefit. – Robbie Dee May 17 at 11:57
  • 2
    @RobbieDee, "What is more important - working code or code that looks the same?" is a fault dichotomy. I want working code that looks the same. And if I have the latter, I also have a higher chance of the former as I'm working with folk who care about their code and so are more likely to make it work. – David Arno May 17 at 13:54
  • 2
    @DavidArno Oh dear, false again. I've managed teams where developers slavishly followed guidelines and used code quality tools. Guess what - bad developers write bad code. Stop looking for shortcuts and employ quality people who add value to your team. – Robbie Dee May 17 at 14:01
4

This link is a recommended discussion of this and related considerations:
Is imposing the same code format for all developers a good idea?

It looks like the main reasons are:

  • It helps with version diffing
  • It helps create a unified body of code that belongs to the whole team. This may help with new team members understand the code base sooner.

The recommended discussion also includes reasons against code-formatting requirements and the considerations of implementing. So it is great reading for understanding the full dimensions of the topic.

The dimensions often include strong personal preferences where getting support for code-formatting probably involves other approaches in addition to describing the reasons for it.

  • Will it actually take developers' egos away? In mature languages certain aspects of formatting can be taken to be standard, but I haven't yet seen a case where all aspects of formatting can be performed well entirely by machine - if it were so, the language itself would enforce them. And the limitations of version diffing which cannot grasp the meaning of code and compare that, isn't much of an argument. – Steve May 17 at 12:08
  • Yeah, that's a good point. Okay, I've updated this answer to recognize that there is a human dimension when choosing code-formatting guidelines. – DC Slagel May 17 at 17:57
  • 1
    Version diffing has nothing to do with automatically formatted code. A diff is simply going to tell you the difference between two files, it doesn't care how the code is formatted. – 17 of 26 May 18 at 14:40
2

It goes without say that a different code formatting by different developers is just evil, like a Word document with 20 fonts. No need for a counter-argument against different code formats.

This still is no positive argument pro uniformed code formatting. Automatic code formatting avoids deviations, and as said:_

  • no subjective beauty standard;
  • better diffing, finding code repetitions, as the code is in a canonical form.

The standard imposed must however be adequate: either an industry wide standard, or something sufficiently neutral. But not a companies chief developer's "standard."

For instance when the code formatting undoes line wrapping, readable code might become unstructured.

Then exceptions may exist:

A java project used the builder pattern to create in fluent style hierarchical data. Fortunately there where comment pragmas to suppress automatic code formatting when the source was commited to version control.

Something like the following, a code formatter would regularize.

// @formatter:off
def()
    .beginA()
        .withB()
        .withC()
    .endA()
    .beginA()
        .withB()
        .withC()
    .endA()
    .beginA()
        .withB()
        .withC()
    .endA()
.build();
// @formatter:on

As code formating often is embedded in code guidelines, and code analysis tools, it should be treated in that context. As

if (123 == n) (constant first in equality) could be fine in C to prevent unintentional assignment (=), but is senseless in java.

That is, if formatting is documented, it might better be placed in a more interesting context.

In short:

  • automatic: certainly
  • it stays a running target, to be maintained, refined

Not the answer you're looking for? Browse other questions tagged or ask your own question.