-1

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 :)

mguijarr
  • 226

2 Answers2

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 new team members understand and learn 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.

DC Slagel
  • 166
3

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
Joop Eggen
  • 2,629