* Handling of multiple newlines to break sections, or none to group related functions (e.g. a getter with a setter). Sometimes it's even best to move functions around for better grouping.
* They don't factor out an expression into a separate variable.
* They destroy `git blame`. This one is avoided if the tooling has always enforced formatting.
That's...not formatting, and there's probably no good deterministic rule for when to do that, anyhow.
* They implicitly enable people to write deeply nested code that lacks such factoring, without feeling like anything has gone wrong.
How is this a problem with auto formatters? This is completely on the person/team, not the tool. Even if the repo doesn’t enforce on pre-commit or something, don’t most formatters have the option to only format lines you’ve actually changed?
In pragmatic business environments it's not worth the fuss but I never feel great about anything I make in those kinds of environments anyways, and I always appreciate being able to shine when there's no enforced code formatting.
Compare:
#define/**/Q(x,y)r;char*q/* */=y#x","#y")",*p,x=*p%67;}
/*-IOCCC2020-*/#include/* */<stdio.h>/*-BBQlock--*/
int(y),x,i,k,Q(s[9<<9/* 12 */];float(f)[3];void(Z)
(){*f=r<0?r:-r;f[1]/* 11 1 */=42.5;f[2]=22.5;for
(k=0;++k<39;*f/=(k/* 10 2 */%2?k:-k)*6875.5/i)
y=f[1+k%2]+=*f;k=/* */f[2];p=s+k/2*86+y
;}int(main)(){p=/* 9 o-------> 3 */s;for(;i<1978;*q
>32?k=i++/86-11/* / */,y=(750>r*r+k*k
*4)*4+y/2,*p++=/* 8 L 4 */r<44?y?"+0X+0X"
"+!"[y]-1:*q++/* 7 5 */:10:*q++)r=-41
+i%86;r=20;for/* 6 */(x=13;(i=3600*
--x);*p++="XR"/* */"MOQSUWAY"[x%+
10]-9,*p+=x/10/* */*41)Z();sscanf
(__TIME__,"%d"/* \ / -------+ */":%d:%d",&k,&x
,&i);r=10;for(i/* \ / ------ | */+=(k*60+x)*60;r
+18;*p=k%2?*p%2/* \ / ------ | */?59:44:*p>39?59
:39,i=r--?i:i%(+/* \ / ------ | */3600)*12)Z();for
(p=s;*p;putchar(k/* X ------ | */%2&&k<14?q="End",
printf("%c%c",224|/* __/ \__ | | */(21554>>k&3),"gCS"
"gGMX"[k/2]+65),"E"/* / \ / \ | | */"Gh_BrG"[k/2]+64:*p
),++p)k,"#define/**/"/* \__/ \__/ +--+ */"Q(x,y)r;cha""r*q=y#"
"x\",\"#y\")\",*p,x=*p"/* */"%67;}/*-IOCCC2020-*/#"
"include<stdio.h>/*-BBQl"/* */"ock--*/int(y),x,i,k,Q(")
and clang-formatted version: #define /**/ Q(x, y) \
r; \
char *q /* */ = y #x "," #y ")", *p, x = *p % 67; \
}
/*-IOCCC2020-*/ #include /* */<stdio.h> /*-BBQlock--*/
int(y),x,i,k,Q(s[9<<9/* 12 */];float(f)[3];void(Z)
(){
*f = r < 0 ? r : -r;
f[1] /* 11 1 */ = 42.5;
f[2] = 22.5;
for (k = 0; ++k < 39;
*f /= (k /* 10 2 */ % 2 ? k : -k) * 6875.5 / i)
y = f[1 + k % 2] += *f;
k = /* */ f[2];
p = s + k / 2 * 86 + y;}int(main)(){
p = /* 9 o-------> 3 */ s;
for (; i < 1978; *q > 32 ? k = i++ / 86 - 11 /* / */,
y = (750 > r * r + k * k * 4) * 4 + y / 2,
*p++ = /* 8 L 4 */ r < 44
? y ? "+0X+0X"
"+!"[y] -
1
: *q++ /* 7 5 */
: 10
: *q++)
r = -41 + i % 86;
r = 20;for/* 6 */(x=13;(i=3600*
--x);*p++="XR"/* */"MOQSUWAY"[x%+
10]-9,*p+=x/10/* */*41)
Z();
sscanf(__TIME__, "%d" /* \ / -------+ */ ":%d:%d", &k, &x, &i);
r = 10;
for (i /* \ / ------ | */ += (k * 60 + x) * 60; r + 18;
*p = k % 2 ? *p % 2 /* \ / ------ | */ ? 59 : 44
: *p > 39 ? 59
: 39,
i = r-- ? i : i % (+/* \ / ------ | */ 3600) * 12)
Z();
for (p = s; *p;
putchar(k /* X ------ | */ % 2 &&k < 14
? q = "End",
printf("%c%c",
224 | /* __/ \__ | | */ (21554 >> k & 3),
"gCS"
"gGMX"[k / 2] +
65),
"E" /* / \ / \ | | */ "Gh_BrG"[k / 2] + 64 : *p),
++p)k,"#define/**/"/* \__/ \__/ +--+ */"Q(x,y)r;cha""r*q=y#"
"x\",\"#y\")\",*p,x=*p"/* */"%67;}/*-IOCCC2020-*/#"
"include<stdio.h>/*-BBQl"/* */"ock--*/int(y),x,i,k,Q(")
The beauty is gone!Feel free to not use one in your art projects.
Both are branches of philosophy, but rather distinct from one another.
imho uniformity of what the code looks like > some single person's opinion
it's so satisfying to me when I just run "gofmt" and know the thing is formatted well.
Bike shedding for weeks might happen and is not helpful. On the other side of this argument there are not-so-very-pleasant things as well. A: We follow this-and-this coding convention and we do not like wasting time on discussing it so we follow it to the letter. B: I don't like this small thing that I would like to write differently. A: We follow this-and-this coding convention and we do not like wasting time on discussing it so we follow it to the letter. B: You actually don't follow this-and-this coding convention because you are not following this-and-that rule. A: Yes, that is a change that I liked.
One can easily end up with a very old coding convention that only the oldest developer likes so the oldest developer can now be dictator over everybody else.
The uniformity is not merely for the sake of uniformity.