《 Build the method of 》 note

Chapter four The two work together

Preface

Code specification , Extreme programming (xp) , Pair programming , The different stages of their cooperation , Techniques for influencing others

One 、 Code specification, style specification

It's mainly written rules , principle ： concise 、 Easy to read 、 No ambiguity

Indent

4 Space ,Tab The key will display different lengths in different cases

Line width

Now we can 100 character , In the past, some documents stipulated 80 character （ Previous computer / The typewriter displays the line width ）

Brackets

In complex conditional expressions , Use parentheses to clearly indicate the logical priority

Broken lines and blank { } That's ok

Use “{” “}” To clarify the program structure , It is also easy to see in multi-level nesting ; Every “{” “}” Monopolize one line .

branch

Don't put multiple statements on one line , More strictly , Do not define multiple variables on one line

name

“ Hungarian nomenclature ”： Early computer languages did not do type checking , stay C in int byte char bool It's probably the same thing ; And in some strongly typed languages , There are strict requirements for types , Not suitable for this method ;
Pascal： The first letter of all words is capitalized
Camel： The first word is all lowercase , Then the words follow Pascal form ,lowerCamel
Common practice ： All types / class / All function names use Pascal form ; All variables use Camel form ; Functions are represented by verbs or verb object combinations .

notes

Don't comment on how the program works （How）, And explain what the program does （What）, Why do you do this （Why）, And what we should pay special attention to ;
Complex comments should be placed in the function header ;
Comments should be updated as the program is modified , A misleading comment is worse than nothing ！
notes （ Including all the source code ） It should be used only ASCII character , Otherwise, the portability of the program will be greatly affected

Two 、 Code specification design specification

Programming 、 Relationship between modules 、 General principles for design patterns （ General principles independent of specific programming languages ）

function

cardinal principle ： Do one thing , And do it well

goto

It's better for a function to have a single exit , To that end , You can use goto,

Error handling

Processing parameters

stay Debug In the version , All parameters should be verified to be correct , In the official version , Yes, from the outside （ Users or other modules ） The parameters passed in , To verify its correctness .

Assertion （Assert）

The relationship between assertion and error handling ： When you think something is certain , You can use assertions ;
Assert ( p != NULL);
If you think something may happen , At this time, we need to write code to deal with the error situation

Handle C++ Class in

3、 ... and 、 Code review

Purpose ： See whether the code solves the problem correctly within the framework of code specification

Four 、 Pair programming

summary

It contains const Explanation ：
use const Annotate read-only parameters （ The data that the parameter points to is read-only , Not the parameters themselves ）;
use const Labeling functions that do not change data