Every program should begin with a comment that describes the purpose of the program, author, date and time.
Use blank lines and space characters to enhance program readability.
Omitting the semicolon at the end of a C++ statement is a syntax error.(Again, preprocessor directives do not end in a semicolon.) Syntax errors are also called compiler errors, compile-time errors or compilation errors, because the compiler detects them during the compilation phase.
Many programmers make the last character printed by a function a newline. This ensures that the function will leave the screen cursor positioned at the beginning of a new line. Conventions of this nature encourage software reusabilitya key goal in software development.
Indent the entire body of each function one level within the braces that delimit the body of the function. This makes a program's functional structure stand out and helps make the program easier to read.
Set a convention for the size of indent you prefer, then apply it uniformly. The tab key may be used to create indents, but tab stops may vary. We recommend using either 1/4-inch tab stops or (preferably) three spaces to form a level of indent.
Place a space after each comma (,) to make programs more readable.
Some programmers prefer to declare each variable on a separate line. This format allows for easy insertion of a descriptive comment next to each declaration.
C++ allows identifiers of any length, but your C++ implementation may impose some restrictions on the length of identifiers. Use identifiers of 31 characters or fewer to ensure portability.
Choosing meaningful identifiers helps make a program self-documenting-a person can understand the program simply by reading it rather than having to refer to manuals or comments.
Avoid using abbreviations in identifiers. This promotes program readability.
Avoid identifiers that begin with underscores and double underscores, because C++ compilers may use names like that for their own purposes internally. This will prevent names you choose from being confused with names the compilers choose.
Languages like C++ are "moving targets". As they evolve, more keywords could be added to the language. Avoid using "loaded" words like "object" as identifiers. Even though "object" is not currently a keyword in C++, it could become one; therefore, future compiling with new compilers could break existing code.
Always place a blank line between a declaration and adjacent executable statements. This makes the declarations stand out in the program and contributes to program clarity.
if you prefer to place declarations at the beginning of a function, separate them from the executable statements in that function with one blank line to highlight where the declarations end and the executable statements begin.
Programs should validate the correctness of all input values to prevent erroneous information from affecting a program's calculations.
Place spaces on either side of a binary operator. This makes the operator stand out and makes the program more readable.
Attempting to use the modulus operator (%) with noninteger operands is a compilation error.
Some programming languages use operators ** or ^ to represent exponentiation. C++ does not support these exponentiation operators; using them for exponentiation results in errors.
Using redundant parentheses in complex arithmetic expressions can make the expressions clearer.
A syntax error will occur if any of the operators ==, !=, > = and < = appears with spaces between its pair of symbols.
Reversing the order of the pair of symbols in any of the operators !=, > = and < = (by writing them as =!, = > and = < , respectively) is normally a syntax error. In some cases, writing != as =! will not be a syntax error, but almost certainly will be a logic error that has an effect at execution time.. A fatal logic error causes a program to fail and terminate prematurely. A nonfatal logic error allows a program to continue executing, but usually produces incorrect results.
Confusing the equality operator == with the assignment operator = results in logic errors. The equality operator should be read "is equal to," and the assignment operator should be read "gets" or "gets the value of" or "is assigned the value of." Some people prefer to read the equality operator as "double equals."Confusing these operators may not necessarily cause an easy-to-recognize syntax error, but may cause extremely subtle logic errors.
Place using declarations immediately after the #include to which they refer.
Indent the statement(s) in the body of an if statement to enhance readability.
For readability, there should be no more than one statement per line in a program.
Placing a semicolon immediately after the right parenthesis after the condition in an if statement is often a logic error (although not a syntax error). The semicolon causes the body of the if statement to be empty, so the if statement performs no action, regardless of whether or not its condition is true. Worse yet, the original body statement of the if statement now would become a statement in sequence with the if statement and would always execute, often causing the program to produce incorrect results.
A lengthy statement may be spread over several lines. If a single statement must be split across lines, choose meaningful breaking points, such as after a comma in a comma-separated list, or after an operator in a lengthy expression. If a statement is split across two or more lines, indent all subsequent lines and left-align the group.
Refer to the operator precedence and associativity chart when writing expressions containing many operators. Confirm that the operators in the expression are performed in the order you expect. If you are uncertain about the order of evaluation in a complex expression, break the expression into smaller statements or use parentheses to force the order of evaluation, exactly as you would do in an algebraic expression. Be sure to observe that some operators such as assignment (=) associate right to left rather than left to right.
File translated fromTEXby TTH,version 4.03.
On 6 Aug 2012, 00:17.
File translated fromTEXby TTH,version 4.03.
On 6 Aug 2012, 00:17.
