Personal blog Job week2--code specification and review

I. My thoughts on the following questions about programming norms

1, these norms are the bureaucratic system produced by wasting everyone's programming time, affecting people's development efficiency, waste time of things.

Not supported.

1) Programming specifications are helpful for improving programming efficiency and programming quality. Coding is the responsibility of the programmer, a good information technology product must have high-quality code, high-quality code first

It has to obey some kind of programming specification. If your source code is released as a product, you must ensure that it is packaged and kept tidy as well as other products.

2) Programming specifications help others to quickly understand their own code. 80% of the cost of a software throughout its life cycle is maintained, and almost no software is maintained by its original author throughout its entire life cycle. The programming specification improves the readability of the software, enabling engineers to understand the new code more quickly and thoroughly.

3) Improve the efficiency of team programming. Large amounts of data indicate that software problems or pitfalls, a large part of which is due to non-compliance with the basic criteria, if you can clear the rules early in the project, will avoid a lot of trouble. To simplify the work, everyone who writes software in the team must adhere to the programming specifications.

In addition, everyone is accustomed to looking at their own code, if members of the team can unify the code of the programming, then people will be more patient when reading others ' codes.

2, I am an artist, craftsman, I have their own norms and principles.

Retort.

The ability of a person is limited, and a successful software must be inseparable from the efforts of all members of the team. When a team develops a software together, everyone must abide by common programming norms. Otherwise, the programming specification of your own personality can be a hindrance to other members of your team reading the code.

3, the norms can not be forced to all, should allow a lot of exceptions.

Retort

Since it is a norm, it must be made clear and everyone should abide by it. For example, in the same project group it should be clear that the legality check of interface function parameters should be the responsibility of the caller of the function or the interface function itself. For the problem of the validity of the parameters of the interface function between modules, there are two extreme phenomena, namely: either the caller and the callee do not check the parameters, and the result omits the necessary processing of the legality check, which causes the hidden trouble; either the caller and the callee are checking the parameters for legality. This situation does not cause problems, but it produces redundant code and reduces efficiency.

"Rapid software Development" pointed out that the stability of a software is often more important than its function, once the team members of the code cohesion vulnerabilities, software instability will be very high, thus affecting the overall effectiveness of the software.

4, I am good at coding specifications, you listen to my good.

Retort.

The purpose of coding specification is to improve the coding efficiency of the whole team, so in addition to rationality, it should conform to the coding habits of most members. If the coding specification you are using is not designed specifically for your project, it may not be the best solution for your project. Again, this is just syntax: non-optimal does not mean bad. It may not be ideal for your project, but it doesn't mean it's not worth complying with. Yes, you don't get the benefit of your project, but the benefits for a big company are huge. In addition, it is generally better to develop coding specifications specifically for a particular project. It's understandable that a project has its own coding style.

Second, code review

Code Review Checklist

General

• Does The code work? Does It perform it intended function, the logic is correct etc.
• Is all the code easily understood?
• Does it conform to your agreed coding conventions? These would usually cover location of braces, variable and function names, line length, indentations, formatting, and comme Nts.
• Is there any redundant or duplicate code?
• is the code as modular as possible?
• Can any global variables be replaced?
• Is there any commented out code?
• Do loops has a set length and correct termination conditions?
• Can any of the code being replaced with library functions?
• Can any logging or debugging code be removed?

Security

• Is all data inputs checked (for the correct type, length, format, and range) and encoded?
• Where Third-party Utilities is used, is returning errors being caught?
• is output values checked and encoded?
• is invalid parameter values handled?

Documentation

• Do comments exist and describe the intent of the code?
• Is all functions commented?
• Is any unusual behavior or edge-case handling described?
• is the use and function of Third-party libraries documented?
• Is data structures and units of measurement explained?
• Is there any incomplete code? If So, should it is removed or flagged with a suitable marker like ' TODO '?

Testing

• Is the code testable? i.e. don ' t add too many or hide dependencies, unable to initialize objects, test frameworks can use methods etc.
• Do tests exist and is they comprehensive? i.e. have at least your agreed on code coverage.
• Do unit tests actually test, the code is performing the intended functionality?
• is arrays checked for ' out-of-bound ' errors?
• Could any test code being replaced with the use of an existing API?

You'll also want to add-checklist any language-specific issues that can cause problems.

The checklist is deliberately not exhaustive of all issues that can arise. You don ' t want a checklist, which are so long no-one ever uses it. It ' s better to just cover the common issues.

Optimize Your Checklist

Using the checklist as a starting point, you should optimize it for your specific use-case. A great a-to-do-is-get your team to note the issues, arise during code reviews for a short time. With this data, you'll be able to identify your team's common mistakes, which you can then build into a custom checklist. Be sure to remove any items of that don ' t come up (the wish to keep rarely occurring, yet critical items such as security Related issues).

Get buy-in and Keep It up to Date

As a general rule, any items on the checklist should is specific and, if possible, something you can make a binary decisio n About. This helps-avoid inconsistency in judgments. It is also a good idea to share the list with your team and get their agreement on its content. Make sure to review the checklist periodically too, to check for that all item is still relevant.

Armed with a great checklist, you can raise the number of defects you detect during code reviews. This would help you to drive up coding standards and avoid inconsistent code review quality.

　　　　

Personal blog Job week2--code specification and review