1. production - make the design a practical entity

2. write code for other humans to read; they must acheive understanding

3. code for testing and maintenance

4. programming practice

   1. translate design into simple, clear code

   2. coding is language independent

   3. approaching the design hierarchy

      1. top-down vs. bottom up implementation

      2. design need not dictate implementation

      3. incremental build and test

      4. top-down and bottom-up testing are different

      5. poor design (ill structured, incomplete) leads to a top-down implementation (design in code).

      6. layered designs lead to bottom-up implementation

      7. of course, you can do both

      8. local implementation increments vs. global requirements ones

5. structured programming

   1. the object-oriented x of the 70s

   2. static and dynamic program structure

   3. discovering dynamic behavior from static structure

   4. structured programming makes dynamic behavior correspond to static structure

   5. single-entry, single-exit statements - if, loop, sequence

   6. simplified verification

   7. hierarchical linerization

   8. ease of understanding guides program structure

6. information hiding

   1. data structures modeling problem and solution concepts

   2. only a limited number of operations make sense for a data structure

   3. hide the data structure, present the operations

      1. no direct data structure manipulation preserves integrity

      2. reduces coupling and improves maintenance

      3. hides data structure complexity

   4. selective direct access to data - read-only access

   5. language support via data abstractions

      1. some languages fake data abstractions better than others

   6. data abstraction is always useful, supported or not

7. programming style

   1. programmers tend to do what they're told when given clear objectives

   2. general rules for writing code - standards from Taligent and gnu; standards for Java and C++

   3. descriptive names - hungarian notation, original and modified

   4. single entry, single exit control constructs

   5. few or no gotos

   6. hide information

   7. create descriptive types

   8. shallow nesting

   9. small modules

   10. simple module interfaces

   11. consistent and clear program layout

   12. avoid side effects

   13. deal with the unexpected

   14. the vexing comment

       1. no code comments, generally

       2. input-output oriented procedure comments

       3. high-level module comments

       4. follow local standards

       5. maintaining consistency between comments and code

   15. object-oriented code and the law of demeter

       1. procedural coding guidelines apply to method development

       2. additional guidelines to cover state and method interaction

       3. the law of demeter attempts to control inter-object complexity

          1. avoid non-parameter, non-instance objects

             1. globals, scope violators, and friends

          2. use only instance, parameter, local, global and recursive objects

This page last modified on 1 March 2000.