I gave up reading this very early on. The striving for compactness of the source, in both C and Go, makes it misleading to read. Take
if (argc < 2) puts("y"); else {
for(int i = 1; i < argc; i++) {
if (i > 1) putchar(' ');
printf("%s", argv[i]);
}
putchar('\n');
}
A casual skim sees the if followed by an indented block, but that isn't the then-path but the else-path. Now yes, I can read it carefully and follow it, just as if I was debugging someone else's poorly formatted code, but in doing so my attention is being distracted from the main point of the article and frankly I have a huge pile of other things to read that are potentially more rewarding.
Yes, his code style is bizarre at best, both for C and Go.
This is particularly jarring in Go when gofmt exists and is used almost universally (I think this is the first time I see non-gofmt'd code in quite a while).
Your post adds nothing useful to the discussion. There is no point arguing about indenting style in a 7 line program, it's needless pedantry! This is almost exactly the same thing as grammar nazi-ism, and seems to have a similarly negative impact coding related websites.
I think we need to coin a new term - indent-nazi, style-nazi, or something similar - for the purpose of dismissing this kind of post and keeping people on topic.
Actually, "indent-nazism" is a big thing in the Go community. The Gofmt utility, which takes an AST of your code and normalizes it to a common style. Nobody agrees that the style is perfect, a lot of people have religious preferences when it comes to brace placement. But Gofmt ensures that all these people can find a consistent format when it comes time to diff.
GoSublime and go.vim both integrate gofmt into the editor; you start to miss it when refactoring, because you can just shrug and say "gofmt will clean it up when I save" when you move a block to a different function or indent level.
I agree with the grandparent -- seeing non-gofmt code is jarring and deliberately distracting. It's like someone writing an entire Python program with nothing but lambdas.
It's not just diffs, you learn to scan code. The same way that you can't use i++ inline, having consistent indentation and treatment of syntax allows for quicker at-a-glance human parsing.
That code is along the lines of #define true false for reader-hostility. When the formatting makes the code look like it does the exact opposite of what it does, then complaining about it is not in any way "needless pedantry".
I'd just point out that I'm not complaining about something trivial, e.g. open braces on their own line, or a matter of taste, but something fundamentally weird, unexpected, and almost designed to mislead.
