-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
  • 192
  • 1
  • 6
  • What is more important - working code or code that looks the same? Yes you can absolutely have both but usually there is a finite amount of time for polishing and your customer will not thank you if you ship buggy code no matter how nice it looks. – Robbie Dee May 17 '19 at 11:33
  • 1
    @RobbieDee the formatting I am talking about is automatic, it takes no time on developers – mguijarr May 17 '19 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 '19 at 11:56
  • 1
    @Steve Agreed - we have used a similar tool in the past with very little perceivable benefit. – Robbie Dee May 17 '19 at 11:57
  • 1
    I'm voting to close this question as off-topic because it belongs on https://workplace.stackexchange.com (and in fact, has been reposted there) – 17 of 26 May 17 '19 at 12:21
  • 1
    Possible duplicate of [Is imposing the same code format for all developers a good idea?](https://softwareengineering.stackexchange.com/questions/189274/is-imposing-the-same-code-format-for-all-developers-a-good-idea) – jonrsharpe May 17 '19 at 12:34
  • 3
    @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 '19 at 13:54
  • 1
    @DavidArno Given we're talking about *automatic* tools here - your premise is false... – Robbie Dee May 17 '19 at 13:58
  • 2
    @RobbieDee, nope my premise is 100% correct as folk who invest time in setting up automated quality processes produce better code. And those that take the "meh, just get it working" write worse code. – David Arno May 17 '19 at 13:59
  • 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 '19 at 14:01
  • Repost from workplace.stackexchange.com. As I told you there, the benefits of enforcing format are practically zero. The disadvantage was that you have pissed off your lead developer. And a question "what arguments in favour" without wanting to accept "arguments against" is intellectually dishonest. – gnasher729 May 19 '19 at 23:00

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
  • 1
  • 7
  • 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 '19 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 '19 at 17:57
  • 2
    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 '19 at 14:40
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,011
  • 12
  • 10
  • 2
    Promoting `if (123 == n)` shows a concerning disinterest in appropriate compiler-warnings, which would even catch `if (a = b)`. – Deduplicator Sep 10 '21 at 14:39
  • 1
    If (123 == n) is absolutely pathetic. If your compiler settings let “if (n = 123)” pass, then it’s not your code that needs changing, but your compiler settings or your compiler. – gnasher729 Sep 10 '21 at 20:26
  • As said, one measure in java for more code quality was to forbid assignments in conditionals in java. For C it is also very bad code style even in if-else-if(assignment)-else. One also might argue that `n == 123` is more natural (a touch of human sciences, psychology). Also natural: `1 <= n && n <= 123`. – Joop Eggen Sep 10 '21 at 20:51
  • @Deduplicator *Promoting `if (123 == n)` shows a concerning disinterest in appropriate compiler-warnings* Absolutely ***not*** true. GCC's warning is disabled merely by enclosing the mistyped assignment-instead-of-comparision with parenthesis. So if you're coding to something like MISRA where you have to parenthesize comparisons, the warning is ***utterly useless***. GCC won't catch `if ((a=b)||(c==d))` so if you're relying on GCC to protect you, your faith is misplaced. – Andrew Henle Sep 11 '21 at 16:07
  • @gnasher729 See my above comment. Your faith is misplaced also. The more complex the code, and the more difficult it is to spot the bug, the more likely you won't get any warning. – Andrew Henle Sep 11 '21 at 16:07
  • 1
    @JoopEggen Java does not forbid assignment in conditional at all: https://godbolt.org/z/jj5bK3bPx It just doesn't provide for use of non-boolean in boolean contexts, for example by (limited) conversion, aside from auto-unboxing. – Deduplicator Sep 11 '21 at 17:07
  • @AndrewHenle That means the coding-standard fails, and should be fixed or replaced. Whether politics allow that is a different question. Also, unnecessarily complex code is a failure in itself. – Deduplicator Sep 11 '21 at 17:09
  • @Deduplicator I fully agree with that. But good luck getting MISRA and similar standards changed. I was just pointing that compiler warnings are effectively worse than useless in catching inadvertent assignments in conditional clauses. They're worse than useless because people think they work. They don't, and they're more likely to fail the more complex the code is. And it doesn't take very complex code to disable GCC's warnings. So Yoda conditions are just about the only universal and effective hedge against such bugs, and even they only work when the comparison is against a constant. – Andrew Henle Sep 11 '21 at 19:09
  • @Deduplicator yes the decisions were to have a real boolean, separate byte from char and such small things; and a condition is boolean. – Joop Eggen Sep 11 '21 at 20:55
  • 1
    @JoopEggen Even though C++ has a real boolean type (and C added it), all arithmetic types and pointers (as well as many values of class-type) having an obvious boolean value is useful. Implicit (in contrast to explicit or contextual) conversion which looses information is a pain though. Java auto-(un-)boxing wouldn't play nice with it though, and anyway Java goes for more boilerplate. Also, Javas generics in contrast to C++ templates cannot benefit from it either. – Deduplicator Sep 11 '21 at 22:05
  • @Deduplicator ah the quest for ideal programming language design. – Joop Eggen Sep 12 '21 at 01:00