The method of construction reading note 02_3.3--4.4

Read notes

3.3

If you are proficient in a certain aspect, do not have a low-level error, or the emergence of lower levels.

The skill of a person depends on the opposite of the skill, that is, the ability to solve the problem. We must first solve the low-level problem through constant practice, so that it does not appear again, only time to solve the high problem.

To solve the problem, we must first know it, know its why, and then innovate.

4.1&4.3

Code specification problem: A person's code is not only their own to see, teamwork, other people also need to see, their own code to write to let others can understand, not a large, a little structure is not.

Code Style specification at the very least to have indentation (TAB), parentheses, line-wrapping, interview, but also to pay attention to the name of variables, methods and functions, the general use of "Hungarian nomenclature." There are some underscores, casing, and most importantly, comments. A program generally needs to write comments that explain what the program does and why.

Here you have searched for two C + + program naming conventions, please refer to:

Http://www.360doc.com/content/12/0314/12/3767901_194244058.shtml

Http://blog.sina.com.cn/s/blog_567842410100nf09.html

Code specifications are also embodied in Code design specifications . Code design can not just for their own "cool" completely disregard, because their own programs others will see, so need to abide by some general rules.

(1). The design principle of the function is: do one thing and do it well. The function preferably has a single exit.

(2). The most important is the wrong debugging of the program, follow the "28 law", 20% of the wrong work is often required for the entire process of 80% of the time.

(3). When working with classes, there are a lot of things to be aware of in terms of data members, constructors, and so on, not how to design on your own.

4.4 The last completed program must be reviewed in code . The purpose of code review is to identify errors in the code, including coding errors, logic errors, algorithmic errors, and potential errors, as well as promoting common progress among members. Payment review is generally done by the developer, but requires a reviewer. Reviewers can ask questions about the code, various questions, and the developer should give the appropriate explanations. After the code review, the developer records the errors in the program and no longer makes the same mistake. The code review also needs to raise all aspects of the problem.

?

Past views:

Used to know that some methods name, function name set to easy to understand, see the name only, but do not know the setting when there are some problems with the case, and the case can directly reflect the type of a word, such as the word is a constant, variable, function name or method name.

There is the time to write code, know indentation, there are some formatting specifications, but did not consider the book of the code described in the design specifications. Code design specifications relate to the execution efficiency of the program, the invocation method between classes, and so on.

What is bad about this:

If those defined words are not set to the corresponding requirements, and so on later, all are lowercase, do not know what is constant, variable, method name, function name, etc., not easy to view, and others see, will be more chaotic.

Do not consider the design specifications, may be able to write the same function of the program, but the execution efficiency of the program, errors after the error lookup will be relatively slow, and the value of the function of the entry and exit will be more chaotic.

Workaround:

When writing code, you should pay attention to the definition of various types of names, case, to see the name of understanding. In design, consider the process of program execution efficiency, the invocation between classes, or between functions.

?

?

?

The method of construction reading note 02_3.3--4.4