Surface "Programming Craftsmanship" of the code

Part I: Details of the processing code (code surface)

Processing details of the code, is divided into the following several directions, check:

1. Good defense, consider the robustness of the code.
2. Good style. Careful layout.
3. A good name for the file as well as the various parts and functions.
4. Good comments.
5. Error handling, error handling may occur. Guarantee not to crash.
6. Logical, understandable.

1. Defensive

Defensive incentives:

1. A malicious user
2. Client error of use
3. Operating Environment incomplete
4. External runtime issues

If you can use the function of local variables, do not use global variables. If you can use a variable loop body, do not use function-level variables.

Defense essence:

1. Using the appropriate style and specifications.
2. Logical, rather than simple.
3. Open the appropriate warning level.
4. Using static lint checker.
5. Check the return value of the appropriate process.
6. And the rational use of log levels.
7. Cautious type conversion.
8. Appropriate constraints, array bounds checking, pointer

Q & A:

1. For each bug fixes have done a better unit testing.

2. careful layout

1. Adjust the style, adjust the tab width.

3. from a good name

The need for objects named are:

1. variable
2. function
3. Types of
4. Package names
5. Macros
6. file name

• The key to the name from the good name is to understand the named object.
• When naming, rather than clear and concise focus on, but if as a loop counter, you can use a short variable.
• When named functions, because the function is a process, it is best to begin with a verb, table name some logical function.
• When the macro name, all uppercase, and prefixed with the project.
• Description file as the file name function; can split the plurality of logical files.
• Naming be consistent.
• When a name, to determine its scope, likely to have a clear description.

4. Write code skills self-explanatory

1. You do not need to write code to support external documents, as for a large-scale project, maintenance documentation itself is a big challenge, especially the code in constant iteration.
2. It is a good idea to use comments it? No, scattered around the comment, not a good self-explanatory.
3. As a good code book well organized.
   • Preamble code comments corresponding file header, content description file, function, projects belongs.
   • List directory corresponding to the file functions, classes, variables (modern software can use ide)
   • A portion corresponding to the code portion is not recommended single file is too large, it is possible to package several source files into a "portion", representing a large portion of the logic.
   • Chapter corresponds to one source file, he is functionally independent complete set of logical functions.
   • Paragraph code corresponding to each function of the tissue, such as variables and the like on top.
   • Statement corresponds to each statement.
4. Use good style to write simple code
   • Let the normal flow through the code to handle errors or correct branch is always on the front.
   • Avoid excessive nesting.
   • Carefully optimized code, if not easy to understand, comments should be clear.
5. Select a meaningful name
   • All variables, functions, file name, type, should have a precise meaning.
6. Decomposed atomic function
   • A function of operating observe the function name will be able to know the function function.
   • Keep it short.
7. Use the appropriate type
   • Such as variable does not contain a negative value, then the direct use uint
   • If the variable can not be modified, then modified by const
8. Highlight the important code
   • Hide unimportant information and code
   • Limit the number of nested conditional statements. Avoid processing conditions are important nesting hidden.
9. Grouping of related information
   • By using the mechanisms of language, grouping related information, go in, the package is in (c), is the file.
10. Properly handle errors
    • Do not return an error meaningless, each layer handle their own errors. If an error occurs in the disk access code, then this layer on the handling of disk errors, then an error is thrown up, the top may be open file processing errors.
11. Code for a self-describing, what documents need?
    • It requires a description of the entire system and the role of documents
    • The summary documentation and structure of the system design documents
    • Test Specification

5. Write an appropriate comment

1. Only you need to write enough notes, too far.
2. For complex place, to explain why doing so is more important, as what has been done, if the code is self-explanatory, has been dealt with very clearly.
3. Do not documented bad code, rewrite it. You can use unit tests to ensure that no damage function after rewriting.
4. Comments should live in the present, do not describe things have changed, and do not tell a thing in the past is what to do.
5. When you modify the code, maintaining all the comments around.

6. Handling errors

1. Cause The summarize classified into three types:
   • User error, user error, or an input operation
   • Programmer error
   • accidents
2. In order to control the error code, we need to do:
   • Made an error when an error occurs
   • Detect all possible errors report
   • Properly handle errors
   • We can not handle the error propagation
3. Error reporting mechanism
   • Do not report such an error occurs, it is aborted, but not a good idea.
   • Use the return value
   • Using the wrong state variables, such as errno c language, do not use this way
   • abnormal
   • Use signal
4. Processing error
   • When handling errors
   • Treatment as early as possible (as late as possible in the process), there is no good or bad, compromise
5. The method of cleaning up after an error