Computer Science MTSU C++ Programming Conventions (2nd ed.) "A well-written program not only operates correctly and efficiently, but is also easy to maintain over its useful lifetime of perhaps several years and a variety of computer configuration changes. Straightforward, easy-to-read code is definitely an asset in program maintenance. It is helpful if the formatting of the source code follows the structure of the program." (Neumann) "The guiding principle in our indentation convention is that statements that begin in the same column should have the same logical importance. One should be able to understand the general outline of a program by reading only the lines (either comments or statements) that project furthest to the left. As one needs increasing detail about how some particular subtask is performed, one reads farther to the right." (Conway & Gries) Use these conventions for all C++ source code: 1. Identifiers: Identifier names should be chosen to reflect their role in a program. Variables should be identified in a way that makes clear the significance of the data contained within the variable (e.g., "numberOfChildren"). Functions should be identified in a way that makes clear what they do (e.g., "CalculatePaymentAmount"). (Hoppe convention): In an identifier naming scheme proposed by Jirka Hoppe, the first letter of the names of functions, user-defined data types, and classes are capitalized but NOT the beginnings of identifiers that are names of variables or class methods. For example, under this convention the variable "WeeklyAvgRainfall" would be written "weeklyAvgRainfall". Identifiers should be in "camel case", that is, when identifiers are formed by using several words together, the first letter in each word should be capitalized (except possibly the first word) and the rest written in lower-case letters (or digits). Be consistent when using abbreviations. For example, if you use "avg" for "average" in, say, "avgFamilyIncome" then use it in any similar identifier name, say, "weeklyAvgRainfall". 2. Constants: Identifier names should be given to constants whose value can be meaningfully described by such a name. These include common symbolic constants (e.g., PI = 3.1415), implicit inputs (values apt to change given changes to problem specifications, e.g., MaxUsers = 16), and "magic numbers" (e.g., SectorsPerTrack = 9). For emphasis, constant-identifiers are often written entirely in upper- case with underscores separating words (e.g. SECTORS_PER_TRACK). 3. Line limits and continuations: Usually no more than 80 columns of text should appear on one line. If a statement cannot be completed on one line, it will be continued on the next line indented at least two spaces beyond the normal indentation. C++ Programming Conventions Page 2 4. Control statements: THEN/ELSE clauses and loop bodies will be indented one level (e.g. one tab or 4 spaces) from the line containing the control statement. The following illustrate these indentation patterns. -Conditional Instructions if (predicate) if (predicate) { { statement(s); statement(s); } } else if (predicate) if (predicate) { { statement(s); statement(s); } } . . . else else { { statement(s); statement(s); } } -Repetition (Looping) Instructions while (predicate) { statement(s) comprising body of loop; . . . } for (initializer;predicate;modifier) { statement(s) comprising body of loop; . . . } do { statement(s) comprising body of loop; . . . } while (predicate); C++ Programming Conventions Page 3 4. Control statements (continued): --SWITCH statements SWITCH statements may take one of two forms shown below. If EVERY alternative clause is only one statement long, then the first form may be used; otherwise the second, more general form should be used. switch (expression) { case alternative: statement; break; case alternative: statement; break; case alternative: statement; break; . . . default: statement; break; } switch (expression) { case alternative: statement(s); . . . break; case alternative: statement(s); . . . break; . . . . . . default: statement(s); . . . break; } where "alternative" is a case label constant. C++ Programming Conventions Page 4 5. General program structure: // OLAnnn BY student name, CSCI cccc-sec, Due: mm/dd/yy // PROGRAM ID: prog.cpp / one-line description ... // AUTHOR: student name ... // INSTALLATION: MTSU ... // REMARKS: short description and comments ... // . 1 . 2 . 3 . 4 . 5 . ...8 //3456789012345678901234567890123456789034567890123456...0 #include using namespace std; int main() { ...your C++ statements here... } 7. Declarations: Each item within a declaration section should be on a line by itself with a comment describing the identifier; e.g., char typeSpray; // Type of Chemical ... int acreage; // Acreage to be ... float costPerAcre; // Dollar cost per ... 8. Local Comments: Local comments (i.e., comments within a function) will be indented the same amount as the first statement of the section of code to which they refer. Generally, local comments should appear on a line by themselves ahead of the section of code to which they refer. Comments within declarations may begin in any column. Except for comments within declaration sections, comments should not appear on the same line as code. RECOMMENDATIONS: (These are not hard-and-fast rules) --Generally only one executable statement should be written on each line. Occasionally multiple assignment statements may appear on the same line if it makes it clearer to understand what is being done. --Comments and blank lines should be used to separate logical sections of code. --Generally no more than 5 to 9 user-defined functions should be invoked from within a function. --Functions should generally be short enough to fit on one page. Any function that extends over two pages is almost certainly too long! --For all other situations, use the Golden Rule of Style - "Write it as you would wish to read it."