He already used the right brace style (hanging braces, cuddled else) and the right indentation (tabs, not spaces).
if(foo) {
"no white space after the keywords if, for, while, etc."
if(foo)
> This is all very well if you have a friendly, high level scripting language like Ruby, but I'm definitely glad I don't have to write a C compiler where functions can take arbitrary blocks of code.
That's a surprisingly good setup because in Smalltalk(one of ruby's main ancestor languages)
if/else is a method which takes a block closure.
a ifTrue: [ l log: 'a is true'] ifFalse: [ 'a is false']
in ruby if else is a syntatic construct
if a
l.log ('a is true')
else
l.log ('a is false')
end
#define if(X) LET(_it,X) if (_it) #define LET(name, X) \
for (int let_once_=1, name=(X); \
let_once_; \
let_once_=0)
#define private public
#include "foo.cpp"
#undef private #define public protected #define else
#define struct union
Everyone must support the space character, it cannot be banned. But a simple commit hook to ban tabs can make indentation and alignment not get messed up over time with many collaborators with default-configured editors (that mess up and use tabs for alignment).
The tab character is a nice idea, but they do not seem to have worked out at all. I'd much rather have syntax-aware indenting in the editor, now that available compiler technology and CPU power make it practical.
Also, do you really want to be pressing the space bar twelve times, instead of tabbing three times?
I've seen the results of spaces-only: inconsistent, sloppy indentation, 7 or 9 spaces instead of 8, as long as it looks "indented" enough.
How, specifically does the tab character "not seem to have worked out at all"?
I'm not saying you're wrong for using spaces, just wondering...
The key is great. I use it all the time. Of course I don't want to press the space bar twelve times instead of tabbing three times. Of course I don't want sloppy indentation with 7 or 9 spaces instead of 8. Is this an actual problem? I've literally never seen either one in ~25 years of using languages that need indentation. The editor takes care of it.
The problem with the tab character is that there's no standard for how wide they're supposed to be, and so everyone uses them differently. Sure, in theory you use one tab character to indicate one level of indentation, and everybody can be happy. In practice, they're often not used that way. People will use two-space tabs with four-space indentation, using two tab characters to indent. People will use eight-space tabs with four-space indentation, using four spaces for one level of indentation, a tab character for two levels, a tab character followed by four spaces for three levels, etc. Some people just blithely mix and match for no particular reason. Put either one into an editor with different tab settings and it explodes into a huge mess.
Tabs just don't work out in a collaborative environment. It is too complicated for a heterogenous editing environment to get correct, so no such environment gets it correct in practice and code ends up a huge mess.
You could even make a plugin that works without collaboration by others: check out the file in your preferred style and transform the changes back into the original style.
We'll probably get there in a few more years, as we get comfortable with adding more power to these systems, and taking advantage of compiler technology for things other than generating code.