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
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.
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.
- automatic: certainly
- it stays a running target, to be maintained, refined