The biggest thing to know about coding standards is that many programmers need to stop being giant dicks about it.
By this I mean I've come across people who insist on:
if (blah) {
// ...
}
else ...
(You're going to be first up against the wall when the revolution comes btw)
Others who insist on 2 space, 4 space or tab indents.
Others who insist on braces on new lines (in Java) or on the same line (in C/C#/C++), both of which go against the prevailing style.
Others who want to static import everything (in Java).
Etc.
None of it actually matters in the absolute sense. The key to working well in an organization is being flexible enough to just do what everyone else does.
At Google we use 2 space indents and 80 character lines (100 for Java). I actually like it now but in past lives I'm more used to 4 space indents and no line length limit. Whatever. It doesn't matter. Get over it (and yourself).
You see this same sense of heightened inflexibility in build systems. Some diehards like Ant (in Javaland) because you can arrange your project anyway you like (with enough XML). These same people chafe against the predefined structures of Maven.
The point of Maven (and organization-wide coding standards) is not that they're empirically the best. It's that they're consistent. You look at any Maven Web app and you'll know where to find things. Seen one, seen em all. Every Ant build is different.
Yet people continue to insist their (non-prevailing) differences actually matter and their exceptions should live on. They don't and they shouldn't.
Code should be written for those that come after you and read it knowing nothing about it. Knowing where to find it and being familiar with the conventions is a huge help.
And don't even get me started on the ASI (automatic semicolon insertion) crowd. That has to be the most idiotic idea in the history of coding styles: forcing people to learn a set of rules about when ASI happens (some of which can be quite subtle) for absolutely zero gain.
Seriously, if any of this gets your back up and you want to protest how ASI is good or how your weird style is important, just stop being a giant d-bag. Your teammates would secretly thank you for it.
In C, braces on a new line is the prevailing style? I've been doing the opposite because that's what K&R C does (except for braces that define functions).
Respecting Google's Java standards, sure. Respecting GitHub's JavaScript guidelines? No thanks. When organizations have earned the right to tell its employees to use a style it's no problem to do things slightly differently than you normally would, but when they haven't earned it...
By this I mean I've come across people who insist on:
(You're going to be first up against the wall when the revolution comes btw)Others who insist on 2 space, 4 space or tab indents.
Others who insist on braces on new lines (in Java) or on the same line (in C/C#/C++), both of which go against the prevailing style.
Others who want to static import everything (in Java).
Etc.
None of it actually matters in the absolute sense. The key to working well in an organization is being flexible enough to just do what everyone else does.
At Google we use 2 space indents and 80 character lines (100 for Java). I actually like it now but in past lives I'm more used to 4 space indents and no line length limit. Whatever. It doesn't matter. Get over it (and yourself).
You see this same sense of heightened inflexibility in build systems. Some diehards like Ant (in Javaland) because you can arrange your project anyway you like (with enough XML). These same people chafe against the predefined structures of Maven.
The point of Maven (and organization-wide coding standards) is not that they're empirically the best. It's that they're consistent. You look at any Maven Web app and you'll know where to find things. Seen one, seen em all. Every Ant build is different.
Yet people continue to insist their (non-prevailing) differences actually matter and their exceptions should live on. They don't and they shouldn't.
Code should be written for those that come after you and read it knowing nothing about it. Knowing where to find it and being familiar with the conventions is a huge help.
And don't even get me started on the ASI (automatic semicolon insertion) crowd. That has to be the most idiotic idea in the history of coding styles: forcing people to learn a set of rules about when ASI happens (some of which can be quite subtle) for absolutely zero gain.
Seriously, if any of this gets your back up and you want to protest how ASI is good or how your weird style is important, just stop being a giant d-bag. Your teammates would secretly thank you for it.