A 2 space indent is more compact. A 4 space indent is more readable for older people. Putting braces around blocks on their own lines highlights blocks. Putting braces inline is again more compact. Outdenting declarations highlights an important piece of information. Keeping them in line focuses on blocks. And so on.
None of these choices are particularly important. Being CONSISTENT does. This is his site, and his code. Adapt. If he comes to work with you, then he'll need to adapt to you.
Yes, it is a shock to see someone whose style is unfamiliar to you. Each of your choices has a reason behind it, and you may have thought through all of them. But it matters less than you think. Grow up and get over it. Be consistent with code around you.
I have been wondering for a while now why is it that everybody is stuck with this typewriter/punchcard mentality and assumes that only a fixed-width (non-proportional) font could be used to display program code on a computer screen. Would it not be more appropriate, in this century, to realize that since indentation (and spacing in general) is essentially something that only pertains to the graphical representation of program's code, it should be left to the editor/viewer software (and its user) to set, given a single tab or space character, the number of pixels (or inches or any other unit of length) that should be used to represent the indentation or white space? This should have nothing to do with the width of a character, and therefore using modern proportional fonts should be just as convenient and natural as it is when using a word processor.
False assumption.
Suppose a language exists which: 1.) truncates all characters beyond the 80th prior to interpretation; 2.) will throw an exception during run-time if tab characters are used for indentation; 3.) strictly defines, in BNF, valid cases for the first 7 column-wise characters, of which 7 spaces is distinctly meaningful.
Although it may be "this century", I think I speak for more than a few who continue to maintain the corrected mistakes of our predecessors out of economic necessity...and I'm not talking about reaping a paycheck either.
The thing is - there isn't much consistency in his syntax. The most obvious example is the indentation, that appears to be 8 spaces except for one line which is indented with 4; there isn't consistency in whether to have a space or not before semicolons, before and after parentheses, or before and after binary operators.
I sometimes forget what i did in last function, so in my code there might be inconsistencies and a mix of both styles found. I hope to get consistent some day but a working code is the priority right now :)
Good luck with reaching agreement with your fellow developers...
if (foo) {
| blah;
| blah;
| blah;
| blah;
| blah;
| blah;
| blah;
| blah;
| blah;
}That style, especially in other languages with callback hell, feels tight. I can't breathe...
That feeling of can't breathe is far far more of a potent dagger in the heart, than simply scrolling one extra mouse wheel in a Class.
The open and airy, instantly identifiable shape of the code is just like the fresh sea air.
An old friend at work used to call that style "NotepadOpenBinaryFileStyle". The reason that stuck with me was due to its accuracy!
Putting the brace on the same line also makes it easier to grep for function definitions.
So why not:
if (
x>y
)
{
code;
...
}
}
Having more compact code allows to have more code on the screen without using the scrollbar. For me, it is also more readable because I am used to it.
unsigned int countBits (unsigned int x)
{
int i;
int shift; // number of positions to shift to the right
static unsigned int mask[] = {
0x55555555,
0x33333333,
0x0F0F0F0F,
0x00FF00FF,
0x0000FFFF};
for (i = 0, shift = 1; i < 5; i++, shift *= 2)
x = (x & mask[i]) + ((x >> shift) & mask[i]);
return x;
}
P.S. I do not like Hacker News' paragraph formatting
int count_bits(uint32_t x)
{
static const uint32_t mask[] = {
0x55555555,
0x33333333,
0x0f0f0f0f,
0x00ff00ff,
0x0000ffff
};
for (int i = 0, shift = 1; i < 5; ++i, shift *= 2)
x = (x & mask[i]) + ((x >> shift) & mask[i]);
return x;
}