Habits that programmers should develop

Code review:

As I mentioned in my previous blog (I can tell you clearly), I have left Google. Although I have received many good offers, I have not decided where to go. Technically speaking, I am not employed by anyone during this period, although it may make my (former) colleague or boss a little nervous, but I think we should write something interesting about the technology.

Google is indeed a cool company. Google has done a lot of amazing things inside and outside the company. Here I would like to introduce things that do not involve trade secrets, but are fresh to outsiders.

The reason why Google's code is excellent is actually very simple:They place great importance on code review. Code review is not unique to Google. It is widely recognized as a good (Code Quality Improvement) method, and many people have adopted code review in daily development. But I haven't seen any big company (like Google) that is widely used. At Google, any product or project code requires a valid review before it is checked in (code repository.

Everyone is involved in code review, and here I am not referring to informal review:It is a very important and common rule in software development.. Not only product code, but all code needs to be reviewed. Review Code does not require a lot of effort, but the results (compared with no review) are quite different.

With regard to code review, Jonathan danylko argues that "code should be checked frequently (including self-check and other colleagues' checks ). Do not look at others' checks as harsh on the Code style. They should be viewed as constructive criticism. Personally, I often check your code and ask myself, "How can I write better ?" This will accelerate your growth and make you a better programmer ."

What do you get from code review?

It is obvious that another person checks the code to be submitted to help find bugs. This is a well-known and frequently-mentioned benefit of code review. However, based on my experience, this is the least valuable benefit. People can indeed find bugs in code reviews. However, frankly speaking, the vast majority of bugs found during code review are small bugs that some code authors can find in a few minutes. Bugs that really need time to be found cannot be checked during code review.

The biggest benefit of code review is that it is a social channel.If you know a colleague will check your code during programming, your program will be different. The code you write will be more neat, have better comments, and have a good structure-because you know someone will check your code and you are very concerned about their opinions. If there is no code review, you know the code will be reviewed at the end. Because it is not about to be checked immediately, it is not urgent for you. Therefore, you will not try to perform self-check first.

Another major benefit of code review is that you can share your knowledge.In many development teams, everyone is responsible for and focuses on a core module. Other colleagues are not concerned about others' work unless their code cannot run due to a module problem. The result is that only one person is familiar with the code of each module. If the programmer leaves the company on vacation, no one knows the code. If there is a code review, at least two people will be familiar with the code-the author and Reviewer of the Code. The reviewer is not as familiar with the Code as the author is-but he is also familiar with the design and structure of the Code, which is invaluable.

Of course, nothing is so simple. In my experience, it takes some time to practice code review. I have noticed that inexperienced reviewers often fall into some code review traps that often cause a lot of trouble and leave a bad impression on those who want to try code review, it became a major obstacle for them to adopt code reviews.

The most important rule for code review is to find problems in the code to be submitted --What you need to do is to confirm that the code is correct.. A common mistake is also an easy mistake for new users who are just getting started with code review. That is, reviewers will determine whether the code is implemented according to their own ideas.

There are usually dozens of solutions to a problem. When you select a solution, there will be millions of code implementations. Therefore, as a reviewer, your work does not ensure that the Code is written in your way-because this is impossible. The reviewer's job is to ensure that the code written by the original author is correct. If you do not comply with this rule, you may encounter difficulties everywhere. At the end of the review, you are in a bad mood. It is certainly not a good thing for you.

The problem is that this is a mistake that will be made unconsciously. Suppose you are a programmer. When you are looking at a problem, you will get a solution of your own-and what you think you are seeing is the problem (which should be used) solution. If you want to become a good reviewer, you need to know that this is not correct.

The second misunderstanding is that people feel that they must say something (only code review is done). The author of the Code spent a lot of time and effort writing code-shouldn't you say something?

The answer is: You shouldn't.

If you just say "Oh, it looks good !", This is always true. On the contrary, if you constantly search for and blame some "problems", then I am sure your credibility will be lost. If you constantly create something to talk about, the author of the Code will think that when your comments are just to avoid the cold scene. Since then, your opinions will not be taken seriously.

The third misunderstanding is speed.You should not rush to complete a code review-but do not delay. Your colleagues are there waiting for your review results. If you and your colleagues don't want to take the time to review the code or keep delaying it, you will get bored with this review and think that future code review will only cause trouble. It seems that the Code review will interrupt your work. You do not need to discard your tasks immediately when someone asks you to review them. But within a few hours, when you take a break at work-have a cup of tea, go to the bathroom, chat, and take a walk. When you come back to work, you can start and complete the code review. If you do this, no one will stand by you and wait for you to give the review results.

 

Http://blog.jobbole.com/1171/

 

 

Encoding specification:

In what we did on Google, another system that made me feel exceptionally valid and useful is a strict coding standard.

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.

At Google, I can view any code and access all Google Code libraries. 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 easily understand them. This shocked me because I thought these specifications were trivial. They cannot have such a big role-but they have played such a big role. 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 written by you or by your colleagues, it is written by a person who is 11 different time zones from you-they all have a unified structure and the same naming rules.
-- The effect is huge. 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 proves my skills and creativity. 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 .) The norm actually makes 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. This is okay. Similarly, this is just a Syntax: non-optimal does not mean that it is not 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 that no one deserves to set standards for them, and any changes to their code are a kind of damage. 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 or whether you have specifications. (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 .)

 

Http://blog.jobbole.com/1252/