Is it good or bad for programmers to encounter such a leader during code review?

Today, when I was browsing the website, I saw a post from someone else. He had just joined a new company. During the code review, the leader made some changes to his code, and the programmer felt that many of them were unnecessary. What do you think after reading the post above?

view

My opinion is:

First, it is really good to meet such a leader. Let's not discuss whether the leader's modifications are necessary or not. Just seeing that the leader helps you with code review and modifications in these small places shows that the leader is very responsible. Which of these modifications by the leader and yours is more standardized? It's hard to say, but I personally think that the leader's modifications are indeed very standardized, at least there is nothing wrong with them.

Second, I think some of the changes made by the leader are unnecessary. For example, in the red box above, I changed setVisible to show. It is not necessary, but I think the leader's change is easier to understand and identify. The leader also changed the name of the constant above, which is indeed unnecessary.

There is another place, for example: a.do1() a.do2(), the leader changed it to a.do1.do2(), maybe it is unnecessary, but this modification by the leader can make the code more concise and look more convenient. In terms of code maintenance and update iterations, it really makes you understand it at a glance, very clearly, and facilitates the management and handover of the entire team's work.

idea

In fact, as a team, we should first check whether the entire team has code conventions and specifications to determine how to name variables, constants, methods and functions. If the team has code conventions that define the naming rules, we should still name them according to these rules.

Think about this:

A team leader has more than a dozen people under him. Do you want the leader to adapt to the style of the dozen people, or to make the dozen people unify to the style of the leader?

The unified coding style and specifications will facilitate the maintenance and handover of the entire team's code, as well as the management and upgrade of the code. This requires the team to have a coding specification. Welcome to follow my WeChat public account: Non-famous programmer

For example: the programmer mentioned above is not satisfied with the modification made by the leader. First, check if there is a code standard in the team. What are the regulations for naming in the code standard? If there is, it is your fault if you did not use it according to the standard. If there is no standard, you can talk to the leader. The team should formulate a rule. Can you come up with a rule? I will write according to this specification in the future, which can also reduce the workload of the leader's code review. (http://godcoder.me/)

Code Review

Why do code reviews?

1. Improve quality
2. Discover potential defects and bugs early to reduce accident costs.
3. Promote knowledge sharing within the team and improve the overall level of the team
4. The review process is also a process of reconstructing the thinking of the reviewers, helping more people understand the system.

In fact, I think code review is not just the leader's job. It is also very good for everyone in the team to take an hour every day to review the code of others. Not only can we find the defects and problems of our own code, but we can also learn the advantages of others' code. After all, the review process is also a process of reconstructing ideas for reviewers. Welcome to follow my WeChat public account: Non-famous programmer

In addition, the whole team must have a clear code standard and regulations. The benefit is that code review should be used to do important things instead of spending time on these irregular naming. For naming, let the regulations constrain everyone. The most important thing about code review is to improve the quality of code, discover potential defects and bugs, and find unreasonable places in project modules, such as: system-critical modules, modules with more complex business, modules with higher defect rates, etc.

***, I want to say that the leader in the screenshot is indeed very capable. Judging from the naming alone, it is indeed very standardized. Although it may be a bit too serious, it is indeed worth learning.