I am programming Objective-C for over 10 years now. Alone and together with other people.
My co-founder is also a long-term Objective-C developer and we have different "styles" of programming. When I write code I care about style but only to a certain extend. When I edit my co-founder's source code I simply adopt to his style and that's it. No need to "formalize" anything as long as no really dumb code formatting rule is used that has real technical drawbacks like:
if(expr)
doThisOneLinerWithoutCurlyBraces();
I worry much more about the architecture, correctness and good names for things these days...
A tool like this certainly has its benefits though. Depending on how experienced your team is you want to give junior developers automated guidance.
What would be really cool though is if the formatting rules were applied by Xcode itself. Then each team member could have individual coding style settings. Before pushing to git a "company wide" rule would be applied. This has drawbacks as well: gif giff becomes less useful for sharing between co workers, debugging information is out of sync...
Not sure what the "technical drawbacks" are, unless doThisOneLinerWithoutCurlyBraces is a macro and the author didn't think to do the do { } while (0) trick. The Linux kernel coding style actually advocates this style: http://lxr.linux.no/linux+v3.12.6/Documentation/CodingStyle (line 157, "Do not unnecessarily use braces where a single statement will do.")
I agree with what you're saying though. Making whitespace differences into a build break seems to miss the point a bit. Is that what the author thinks "clean code" means? Consistent whitespace and nothing more? Consistent whitespace is certainly a good idea but there's so much more to a sane code base than how many newlines follow a declaration or whatever.
Without curly braces it is simpler to mess up if you revisit the code, maybe especially adding ambiguous else conditions.
I'm sure you and the GP would never forget to add curly braces when inserting an else, but the junior developer who comes afterwards might, and it's just not a huge deal to have the braces because it's two extra chars.
Quite frankly the Linux kernel coding style is wrong on this one in general, I guess we can assume they are experienced enough to put braces in when adding an else clause and so it's not going to cause them errors. But with junior devs it certainly could.
I definitely don't agree with everything in that style guide either, but I can respect it. I think what I like the most is that it's non-judgmental (or when it is judgmental it is clearly sarcasm). It has nice blurbs like "Please at least consider the points made here." - which is the right attitude for a style guide.
My co-founder is also a long-term Objective-C developer and we have different "styles" of programming. When I write code I care about style but only to a certain extend. When I edit my co-founder's source code I simply adopt to his style and that's it. No need to "formalize" anything as long as no really dumb code formatting rule is used that has real technical drawbacks like:
I worry much more about the architecture, correctness and good names for things these days...A tool like this certainly has its benefits though. Depending on how experienced your team is you want to give junior developers automated guidance.
What would be really cool though is if the formatting rules were applied by Xcode itself. Then each team member could have individual coding style settings. Before pushing to git a "company wide" rule would be applied. This has drawbacks as well: gif giff becomes less useful for sharing between co workers, debugging information is out of sync...