Code style is a lot like fashion style. The content of what’s inside it may not be affected by it, but it’ll affect how people interact with you.
I take style very seriously. Not the kind you show off with a new outfit (I’m a developer, so I only have about two sets of clothes that I alternate between), but the kind you find in a script. I do a lot of peer review, both at OptimalBI, as a university tutor, and in my side-projects, and I’ve seen some bad code style. And I mean BAD. Swear words for variable names, entire projects without white space, nested loops on a single line of code, to name a few cases.
Code style matters. As a peer reviewer, it makes it much easier to understand code and to spot bugs, thus preventing them from becoming a problem. As a developer, it makes it easier to add new features without breaking anything.
But sometimes code style isn’t explicitly bad, just inconsistent. And that often happens due to ambiguity or plain nonexistence of a definitive style guide. That’s where Google Style Guides come in.
Google’s Style Guides are a great collection documenting how Google styles its code. Google has unsurprisingly produced quite a bit of code in their time, and have almost certainly run into every reasonable style dilemma imaginable. This means they have several complete style guides. Lucky for us, these guides are publicly available!
These documents provide guidelines for both common style crossroads like naming conventions and whether there should be a space before that curly bracket, but also less common ones like how to deal with non-ASCII characters and special escape characters. They even contain guidelines on what to do if a situation is not covered by the style guide.
We use these style guides at OptimalBI, if not only as a starting point for our own style guides, then as-is. It’s a good idea to establish style guidelines from the get-go, so your code is always consistent.
Code style may not affect how the computer executes your code, but it’ll sure affect how a developer interacts with and understands it. (It’ll probably also affect how much the people in your office like you.)
Sarah – The tea-drinking programmer
Sarah blogs about her learning experiences as she navigates the road from student to professional.