The importance of code specifications-why should Google execute strict code writing specifications?

In what we did in Google, another system that made me feel exceptionally valid and useful isStrictEncoding specification.

Before I started working at Google, I always thought that coding standards were useless. I firmly believe that these specifications are the waste of programming time and affect people's development efficiency under the bureaucratic system.

I am wrong.

In Google, I can viewAnyCode, enter all Google Code libraries, and I have the right to view them. In fact, this type of permission is available to very few people. However, I was surprised by the fact that so many coding specifications-indentation, naming, file structure, and comment style-all of which made me easily read any piece of code unexpectedly, and easilyUnderstandingThey. This shocked me-I thought these specifications were trivial. They cannot do this much-but they do. When you find that you can read a piece of code only by looking at the basic syntax structure of the program, this time saving can not help but be shocking!

There are many people opposed to coding standards. The following are some common reasons. I have never believed in these reasons.

This is a waste of time!

• 
  

• I am a good programmer and I don't want to waste time doing these stupid things. My skills are good. I can write clear and easy-to-understand code. Why do I have to waste time following these stupid rules? The answer is: unification is valuable. As I said before-any line of code you see-whether it's written by you or by your colleagues, it is also written by a person who is within 11 different time zones from you-they all have a unified structure and the same naming convention-This brings a huge effect. You only need to spend so little effort to understand a program that you are not familiar with (or have never seen before), because you will feel familiar with it when you see it.

• 
  

I am an artist!

• 
  

• This is funny, but it reflects a common complaint. Our programmers are often very conceited about their encoding styles. The code I wrote does reflect some of my characteristics. It is a reflection of my thoughts. It is my skill andCreativity. If you force me to abide by stupid rules, it is suppressing my creativity. The problem is that the important part of your style reflects your thoughts and creativity and is not hidden in these insignificant syntaxes. (If so, you are a pretty bad programmer .) Standards can actually make it easier for people to see your creativity-because they understand your work, people's understanding of you will not be disturbed by unfamiliar coding forms.

• 
  

The shoes that everyone can wear won't match anyone's feet!

• 
  

• If the encoding specification you use is not specifically designed for your project, it may not be the best solution for your project. ThisOK. Similarly, this is just a Syntax: non-optimal does not meanNot good. It is not ideal for your project, but it cannot indicate that it is not worthy of compliance. Yes, you don't get the benefits of your project, but it brings huge benefits to a large company. In addition, code specifications for a specific project are generally better. A project has its own coding style. However, based on my experience, in a large company, you 'd better have a unified coding specification. Specific projects can expand their specific project dialects and structures.

• 
  

I am good at developing code specifications!

• 
  

• This should be the most common type of complaint. It is a mixture of other opposing voices, but it has its own direct attitude. Some opponents believe that they are better programmers than those who develop code standards. Turning over to these rules will reduce the quality of the Code. To be polite, It's a nonsense. It is arrogant and ridiculous. In fact, they mean,No oneIt is worth setting up specifications for them, and any changes to their code are broken. If you cannot write qualified code by referring to any reasonable code specification, you can only say that you are a bad programmer.

When you program according to a certain encoding specification, there must be something that will make you shake your head. Your encoding style will certainly be better than these specifications in some places. However, this is not important. In some places, encoding standards are superior to your programming style. However, this is not important. As long as this specification is not completely unreasonable, the benefits of program comprehensibility will greatly compensate you for your losses.

However, what if the encoding specification is totally unreasonable?

If so, you are in trouble: You are ruined. But this is not because of this absurd coding specification. This is because you are working with a group of idiots. Efforts are required to prevent a good programmer from writing excellent code by making code specifications ridiculous. This requires a persistent, calm, and watery brain. If this group of idiots can enforce codes that are not available, they can do many other silly things. If you work for this group of idiots, you are indeed ruined-no matter what you do, whether you have rules or not. (I am not saying that rare companies are managed by a group of idiots. Unfortunately, we have never been short of idiots in this world, and many idiots have their own companies .)