Five of static code reviews that programmers need to know

The concept of static analysis has been put forward for years, and the technology used to evaluate and diagnose code has matured over the past few years. Software review tools exist in almost every language. These reviews can isolate undesirable code in areas such as arrays, loops, coding styles, design, copying code, naming styles, performance, and so on. At each level there is another complete review for programmers to use.

Here's a reminder that programmers may be tired of reviewing too many vulnerabilities. I have seen a 200,000-line application, measured by current standards, which of course is not much, in addition to running the 200+ review. The report lists 350,000 of the irregularities that need to be fixed, and that has been a bit of a hassle.

To successfully use the review, the key is to limit the amount of the review set. This amount depends on the situation, the programmer should grasp this amount, in order to be more effective.

We usually recommend programmers and their teams to start with a limited review and fix a variety of common problems.

The most exciting part of the review is that it can provide us with code information and the composition of the code. Just because the report indicates an exception to a row does not mean that it is the real problem. A good tool should be able to mark the reported problem as verified, and it can be identified in the comments so that the review tool will understand that the area has been viewed.

So when can we use the review? It is recommended that you run the review every night or when you build a consolidation to ensure that the program is running, especially if the writing of the current code is not strict enough or just finished writing soon. You should run the code at least once while you run the software archeology in the existing code, while refactoring the process to run the review all the time.

The five review tools described in this article are numerical Literal in code,string literal,god method,shotgun surgery and duplicate Code.

Numerical Literal in Code

This is one of the simplest ways to refactor. We've written this code:

Double Salarycalc (double salary) {

Return salary*1.34564333721

}

C++

Two months later, we're going to update the Salarycalc method, and the customer is having trouble looking at the code. Most likely they don't remember the way the method was first written, so they don't understand what 1.34564333721 stands for. It is best to use the Word constants quantity to replace the number. This gives the number a meaningful name, as follows:

Double Salarycalc (double salary) {

return salary* BONUS

}

Static Final Double BONUS = 1.34564333721

C++

When programmers look at the code now, they know at least what 1.34564333721 represents. If you want to refactor, the unit test should not change, and the result should be the same after the refactoring is done.

String Literal

We all know that when time is pressing, we may want to change the code and make it operational as soon as possible. String literal came in handy. This review is especially useful for tasks that will internationalize software. The review needs to be run frequently. Unit tests should not change, and the results should be consistent.

This is not true:

Public Const helloworldmessage:string = ' Hello world! ';

Delphi

That's the right thing to do:

Public Const HelloWorld Message:string =

ResourceManager.GetString (' Msg.helloworld ');

Delphi

This method retrieves the Helloworldmessage string in the resource bundle that can be changed outside of the application and corrects without recompiling.

God method

God ' x ' examines, ' x ' equals Method,class. The review is not just about looking at the code, then pointing out the shortfall.

A summary of this type of review can be summed up as God method; In short, we have a class that contains 50 methods, but only one method can do all the work. Then this method will be marked as God methods.