Google's Coding Standards

[[129666]]

Another system in what we do at Google that I find to be extremely effective and useful is strict coding standards.

Before I started working at Google, I always thought that coding standards were useless. I firmly believed that these standards were a bureaucratic waste of programming time and a hindrance to people's development efficiency.

I was totally wrong.

At Google, I can view any code, access all Google code repositories, and I have access to them. In fact, this access is very rare. But what surprised me was that so many coding standards - indentation, naming, file structure, comment style - all of which made it unexpectedly easy for me to read any code and understand it easily. This shocked me - because I thought these standards were trivial things. They couldn't have such a big impact - but they did. When you find that you can understand a piece of code just by looking at the basic grammatical structure of the program, this time saving is amazing!

There are many people who oppose coding standards. Here are some common reasons, which I used to believe in.
This is a waste of time!

I'm a good programmer, I don't want to waste my time doing stupid things. I'm good at writing code, I can write clear, easy to understand code. Why would I waste my time following stupid conventions? The answer is: consistency is valuable. Like I said before - any line of code you see - whether it's written by you, your colleague, or someone 11 time zones away from you - they all have a consistent structure, the same naming conventions - the effect is huge. It takes so little effort to understand a program you are not familiar with (or have never seen before) because you will feel familiar when you see it.

I am an artist!

This is a funny thing to say, but it reflects a common complaint. We programmers tend to have a lot of ego about our coding style. The code I write says something about me. It's a reflection of how I think. It's a reflection of my skills and creativity. If you force me to follow some stupid convention, you're suppressing my creativity. The thing is, the important part of your style, the reflection of your thoughts and creativity, is not hidden in these trivial syntactic forms. (If it is, then you're a pretty bad programmer.) Conventions actually make it easier for people to see your creativity - because they can see your work, and people's perception of you is not distracted by unfamiliar coding styles.

A shoe that fits everyone won’t fit anyone’s feet!

If you're using a coding standard that wasn't designed specifically for your project, it's probably not the best solution for your project. That's fine. Again, this is just syntax: non-best doesn't mean it's bad. Just because it's not optimal for your project doesn't mean it's not worth following. Yes, for your project, you don't get as much benefit from it as you should, but for a larger company, the benefits are huge. Beyond that, it's generally better to have a coding standard that's specific to a project. It's fine for a project to have its own coding style. However, in my experience, in a large company, you'd better have a unified coding standard, and specific projects can extend their own specific project dialects and structures.

I am good at developing coding standards!

This is probably the most common type of complaint. It is a mixture of several other objections, but it is a direct expression of its own attitude. Some of the opponents are convinced that they are better programmers than the people who make the coding standards, and that stooping to the standards made by these elementary school students will reduce the quality of the code. To put it politely, this is nonsense. It is pure arrogance and ridiculous. In fact, what they mean is that no one is worthy of making standards for them, and any change to their code is a kind of destruction. If you can't write qualified code by referring to any reasonable coding standard, you can only say that you are a bad programmer.

When you program according to a certain coding standard, there will inevitably be some places that make you shake your head in dissatisfaction. There will definitely be some places where your coding style is better than these standards. But, it doesn't matter. There will also be some places where the coding standards are better than your programming style. But, it doesn't matter. As long as the standards are not completely unreasonable, the benefits in program understandability will greatly compensate for your losses.

But what if coding standards are completely unreasonable?

If so, you're in trouble: you're screwed. But it's not because of this ridiculous coding standard. It's because you're working with a bunch of idiots. It takes effort to make the coding standard ridiculous enough to prevent a good programmer from writing good code. It takes a persistent, calm, and watered-down brain. If these idiots can impose unusable coding standards, then they can do a lot of other stupid things. If you work for these idiots, you're screwed—regardless of what you do, whether you have standards or not. (I'm not saying that it's rare for companies to be run by idiots; the fact is, unfortunately, there is no shortage of idiots in the world, and many idiots own their own companies.)