Good Coding Practices John Tullis De Paul Instructor

Good Coding Practices John Tullis De. Paul Instructor john. d. tullis@us. arthurandersen. com Copyrighted material John Tullis 6/13/2021 1

Good Coding Practices Data Declarations • Correct type. • Initialize data structures. • Use descriptive names. • Local rather than global where possible. • Use typedef where appropriate. Copyrighted material John Tullis 6/13/2021 2

Good Coding Practices Data Reference Error Avoidance • Do not reference an uninitialized variable. • Test for array boundaries - do not read/write beyond bounds. • Ensure storage allocated when referencing through pointers • If a variable is defined, it must be used. • Use the #define construct or getenv() where appropriate - no hard coded values in the code. Copyrighted material John Tullis 6/13/2021 3

Good Coding Practices Control Flow Error Avoidance • Ensure all loops terminate. • Place the most frequent cases in switch statements first. • Each switch statement must have a default case. • Every case in a switch statement must have a break. Copyrighted material John Tullis 6/13/2021 4

Good Coding Practices Input/Output Error Avoidance • Open all files before use. • Close all files when done - do not just exit function/method! • Flush all buffered data. • Check spelling/grammer in all log/error file output. Copyrighted material John Tullis 6/13/2021 5

Good Coding Practices Interface Error Avoidance • Check data types on all function/API parameters. • Check values returned from all function/API calls. All nonsystem calls must return a value. Check values from system calls such as getenv(). • If a parameter is passed by reference, does its value get changed by the called function? Should it? Copyrighted material John Tullis 6/13/2021 6

Good Coding Practices Comment Error Avoidance • All functions/methods must have a function/method header. The header must state the function/method name, a brief description, explain the return values, and any error conditions/output. • All variables should have a short inline comment. • A brief comment should precede every “flow of control” statement or statements, e. g. , switch, if/else, while/do. • Each closing ‘}’ for a flow of control statement should have an inline comment such as ‘// end if’ or ‘/* end while */’; especially when that closing curly brace is distant from the start of the statement. • When creating a multiline comment with ‘/* … */’, create both the open and close first before entering the comment text. Copyrighted material John Tullis 6/13/2021 7

Good Coding Practices Modularity Error Avoidance • The behavior of the function/method must be expressable in plain English - in the description of the function/method header. If it cannot, the function should be broken into subfunctions. • Repetitive code in several functions should be replaced by a common function in a separate file and linked in at compile time. Be wary of this in class inheritance as well. Copyrighted material John Tullis 6/13/2021 8

Good Coding Practices Maintenance Error Avoidance • Each function or object method must be well enough documented with comments and clear code that it can be maintained by someone other than the creator. • Any anticipated future changes to functions should be documented in the code with comments identifying what is anticipated and some general direction on how and where the changes should be implemented. Copyrighted material John Tullis 6/13/2021 9