Details in programming

The treasure of a thousand miles is destroyed by the ant nest. Many software problems are not caused by major defects, but by some minor problems. The following are some detailed cases of programming problems that I encountered during the recent software development process.

Case 1:

In a software version, only files with specific prefixes can be scanned and processed from the local directory. The file prefix is manually configured in the configuration file. During the test, we found that many files in the directory that meet the configured prefix were not scanned.

Where is the problem? In order to find the cause of the problem, we added a lot of debugging logs in the code, and finally found that the prefix configuration value is followed by a "*". We also checked the configuration file and found that when manually adding the configuration value, a "*" is added after the prefix and used as a wildcard. But the program does not need to add wildcards, as long as the prefix can be written.

Assume that the prefix of the configuration item represents the prefix. The example before modification is as follows:

Prefix = prefix *

The example after modification is as follows:

Prefix = prefix

A small "*" makes the function of the entire program abnormal. Can you say that the details are not important?

 

Case 2:

A software version reads the PATH value from the configuration file to store the assembled file. During the test, the program encountered an exception. The printed log shows that the file path does not exist. We checked the local disk. This path exists. Why can't the program find this path?

The path in the program comes from two parts. One part is the value of a configuration item (assumed as filepath) in the configuration file, and the other part is generated by the program itself. In order to find the cause of the problem, we also added detailed debugging logs in the code, and found that a slash is added to the final assembled path, as shown in "D: \ Zhou \ mail \ Wang ".

View the relevant code and configuration items. A slash has been added after the configuration item, and a slash is added in the middle when the program finally assembles the path. "\" Is added between "D: \ Zhou \ mail \" and "Wang". In this way, the program can find this "strange" path!

 

Case 3:

When viewing the log generated by a software version, it is found that the variable value printed by a log is very strange. Find the code corresponding to the log in the following format:

Writelog (log_info, "name = % d, age = % d", name, age );

This log prints the value of the variable name and age, but when defining the variable, the name is a struct array, and the age is an integer. But the code "name = % d, age = % d" shows that both variables are printed in the form of an integer (% d). Is it normal? The correct format is "name = % s, age = % d ".

This problem basically does not affect the normal process of the program, because it appears in the log. However, we cannot ignore the problem. If the problem details are not handled properly, a major problem will occur when we accumulate the problem.

 

Case 4:

When running database scripts (SQL files) of a software version, syntax errors are always reported. Check the corresponding SQL statement and find that the following statement is used when initializing a certain variable:

Select namestr = "Zhou"

You may have noticed that in SQL syntax, strings are marked with single quotation marks rather than double quotation marks. This syntax is different from the C language. However, many developers are familiar with the C language syntax. Therefore, in database scripts, double quotation marks are also used to initialize variable types.

The correct SQL statement is as follows:

Select namestr = 'zhou'

 

The above four cases may have been met by many people. So how can we avoid the above detailed problems?

First, we must concentrate on programming. I think many people like to keep their cell phones at hand. They may bow their heads from time to time and wonder why there are so many messages every day. This will lead to scattered energy, and the written programs will naturally not be reassuring, and it is also normal to have bugs.

Second, after writing the program, we must check it several times. Do not think that the function is normal and it will be okay. Don't bother everyone. Check every line of code to find some problems that are easy to ignore. "Be careful when we sail for ten years". Only when we take every program seriously will the program be "worthy" of us.

Third, after writing a program, do not rush to submit it, so that colleagues can check the code. Code lookup is also a type of peer review, which aims to improve the quality of code. A person's vision is limited and many problems cannot be found. Maybe you haven't found any problems, and my colleagues can see them at a glance. The quality of software must be improved through the joint efforts of everyone.

 

Details determine success or failure. This principle is also true in software development. Only by practice and summarization can we improve the quality of code and hide details.

(My microblogging: http://weibo.com/zhouzxi? Topnav = 1 & WVR = 5, No.: 245924426, welcome !)

Details in programming