2. CS 325: Software Engineering March 24, 2015 Implementation Considerations Coding Standards Pair Programming Test-Driven Development

3. CS 325 March 24, 2015 Page 189 Coding Standards Establishing coding standards for a software development process can be contentious, but has several concrete advantages: Provides a consistent level of code quality across teams and developers Facilitates project management, software integration, software reuse, software maintenance, version control, personnel transfer, code review, and software testing

4. CS 325 March 24, 2015 Page 190 Coding Standards: Indentation Kernighan & Ritchie Style (from The C Programming Language) int main(int argc, char *argv[]) {...... while (x == y) { while (x == y) { something(); something(); somethingelse(); somethingelse(); if (some_error) { if (some_error) { do_correct(); do_correct(); } else { } else { continue_as_usual(); continue_as_usual(); } } } finalthing(); finalthing();......} int main(int argc, char *argv[]) {...... while (x == y) while (x == y) { { something(); something(); somethingelse(); somethingelse(); if (some_error) if (some_error) { { do_correct(); do_correct(); } } else else { { continue_as_usual(); continue_as_usual(); } } } finalthing(); finalthing();......} int main(int argc, char *argv[]) {...... while (x == y) while (x == y) { { something(); something(); somethingelse(); somethingelse(); if (some_error) if (some_error) { { do_correct(); do_correct(); } } else else { { continue_as_usual(); continue_as_usual(); } } } finalthing(); finalthing();...... } Allman Style (from Eric Allman’s ANSI C Documentation) Whitesmiths Style (from first commercial C compiler) Many argue that the particular coding standard used is less important than the fact that one is used.

5. CS 325 March 24, 2015 Page 191 Coding Standards: Comments When modifying code, always keep the commenting around it up to date. When modifying code, always keep the commenting around it up to date. At the beginning of every routine, it is helpful to provide standard, boilerplate comments, indicating the routine's purpose, assumptions, and limitations. A boilerplate comment should be a brief introduction to understand why the routine exists and what it can do. At the beginning of every routine, it is helpful to provide standard, boilerplate comments, indicating the routine's purpose, assumptions, and limitations. A boilerplate comment should be a brief introduction to understand why the routine exists and what it can do. Avoid adding comments at the end of a line of code; end-line comments make code more difficult to read. However, end-line comments are appropriate when annotating variable declarations. In this case, align all end-line comments at a common tab stop. Avoid adding comments at the end of a line of code; end-line comments make code more difficult to read. However, end-line comments are appropriate when annotating variable declarations. In this case, align all end-line comments at a common tab stop. Avoid using clutter comments, such as an entire line of asterisks. Instead, use white space to separate comments from code. Avoid using clutter comments, such as an entire line of asterisks. Instead, use white space to separate comments from code. Avoid surrounding a block comment with a typographical frame. It may look attractive, but it is difficult to maintain. Avoid surrounding a block comment with a typographical frame. It may look attractive, but it is difficult to maintain. Prior to deployment, remove all temporary or extraneous comments to avoid confusion during future maintenance work. Prior to deployment, remove all temporary or extraneous comments to avoid confusion during future maintenance work. If you need comments to explain a complex section of code, examine the code to determine if you should rewrite it. If at all possible, do not document bad code—rewrite it. Although performance should not typically be sacrificed to make the code simpler for human consumption, a balance must be maintained between performance and maintainability. If you need comments to explain a complex section of code, examine the code to determine if you should rewrite it. If at all possible, do not document bad code—rewrite it. Although performance should not typically be sacrificed to make the code simpler for human consumption, a balance must be maintained between performance and maintainability. Use complete sentences when writing comments. Comments should clarify the code, not add ambiguity. Use complete sentences when writing comments. Comments should clarify the code, not add ambiguity. Comment as you code, because most likely there won't be time to do it later. Also, should you get a chance to revisit code you've written, that which is obvious today probably won't be obvious six weeks from now. Comment as you code, because most likely there won't be time to do it later. Also, should you get a chance to revisit code you've written, that which is obvious today probably won't be obvious six weeks from now. Avoid the use of superfluous or inappropriate comments, such as humorous sidebar remarks. Avoid the use of superfluous or inappropriate comments, such as humorous sidebar remarks. Use comments to explain the intent of the code. They should not serve as inline translations of the code. Use comments to explain the intent of the code. They should not serve as inline translations of the code. Comment anything that is not readily obvious in the code. Comment anything that is not readily obvious in the code. To prevent recurring problems, always use comments on bug fixes and work-around code, especially in a team environment. To prevent recurring problems, always use comments on bug fixes and work-around code, especially in a team environment. Use comments on code that consists of loops and logic branches. These are key areas that will assist the reader when reading source code. Use comments on code that consists of loops and logic branches. These are key areas that will assist the reader when reading source code. Separate comments from comment delimiters with white space. Doing so will make comments stand out and easier to locate when viewed without color clues. Separate comments from comment delimiters with white space. Doing so will make comments stand out and easier to locate when viewed without color clues. Throughout the application, construct comments using a uniform style, with consistent punctuation and structure. Throughout the application, construct comments using a uniform style, with consistent punctuation and structure.

6. CS 325 March 24, 2015 Page 192 Pair Programming Extreme Programming advocates programming in pairs at one workstation to ensure better focus and stronger oversight. Unfortunately, this practice sometimes leads to tedium, inequity, or conflict.

7. CS 325 March 24, 2015 Page 193 Pair Programming Studies indicate that pairs spend about 15% more time on programs than individuals, but that the resulting code has about 15% fewer defects. By periodically switching between the roles of code-writer to code- reviewer, programmers share knowledge and experience, improve design quality and team communication, and generally express increased job satisfaction. Primary pairing variations: Expert-Expert: High productivity, low learning Expert-Novice: Good mentoring, potential for intimidation Novice-Novice: Sometimes more productive than novices working independently

8. CS 325 March 24, 2015 Page 194 Test-Driven Development One variation of extreme programming advocates beginning the implementation by developing tests that the software initially fails and then minimally adding code until the system passes the tests. E. Clean up code Go back to A and repeatGo back to A and repeat D. Run all tests If tests fail, go back to CIf tests fail, go back to C C. Write production code B. Check if test fails If test succeeds, go back to AIf test succeeds, go back to A A. Write a test Once the code minimally passes the tests, it is refactored to meet standards, and then the entire process begins again.

9. CS 325 March 24, 2015 Page 195 Test-Driven Development TDD has numerous benefits, including: Improved design (an emphasis on functionality needed by users) More modularized code, more focused classes, and looser coupling Fewer defects in final, delivered code TDD also has a few drawbacks, including: Emphasis on unit testing, neglecting integration or system testing GUIs, databases, network configurations require full functional testing Management may not support testing at the expense of coding