CSC 161 Programming Guidelines

This is a quick review of how we'll design, code, and test our programming projects in CSC 161. Please note that these are guidelines, not laws of nature. These are just very brief baby steps to help you complete your projects and write nice, working C++ code.

Last update: Mar 29, 2005... yow, bill

 


1. Design

You must design your program before sitting in front of the computer. It's that simple. How you express yourself is up to you. The book uses "hierarchy charts." there is also an appendix available on UML, the Universal Modeling Language. you can use that too.

What do I do? Well, for projects of these size, I do a two-part design:

  1. Define each class... it's member variables and functions.
  2. Write down pseudo-code for any functions that are complex (like main())

Usually, I will ask to see your design notes one week before your program is due. How will I grade your design work? Easy. I want you to show me that you have spent a significant amount of time working on this problem. This will be evident by your notes and your questions. Don't worry about getting it perfect the first time. The point is to get you to spend time thinking about the problem before trying to code it up.

Some general design pointers:

  • Your classes should generally be flexible and usable by others
  • Your classes should be consistent with a common interface across functions and consistent naming conventions
  • Provide get/set functions to access member variables, as needed
  • Sometimes writing pseudo-code as comments in your function(s) is an easy way to both design and comment your code
  • Create header (*.h) files for each class and compile your class definition before actually implementing all the member functions
  • Don’t start coding before knowing how to solve the problem… the answer is not in the screen.
  • Your design may need to change… so be it!

 



2. Coding Style

The organization and style you use in your actual C++ code is important. For this class, assume you are writing code that must be understood by someone else.

Here are your "Top 10" coding guidelines:

  1. Organization... place each class in its own <class>.h and <class>.cpp files
  2. File header comments... at the top of each file, show your name, the file name, creation date, and a short description of what the file contains
  3. Class/Function block comments... show the class/function name and a brief description of what it does. Make sure you describe the inputs and return values of functions, if any.
  4. Variable comment... briefly describe each non-trivial variable that you declare. A loop index variable may sometimes be considered trivial.
  5. Inline comments... comment difficult or lengthy sections of your code
  6. Good comments... good comments are written for someone who knows C++ and are brief
  7. Naming things... use descriptive names, separate words in a name using capitalization (getName, not get_name), and
    • Function names – start with a lower case letter… example: getInput()
    • Variable names – also, start with a lower case letter… example: myFile
    • Class names – capitalize class names… example: Rectangle
    • Constants – make all letters upper case… example: MAX_SIZE
  8. Indentation - use consistent indentation, just let your programming environment (Mingw) guide you and you'll be fine.
  9. Accessors, modifiers... use "get" to access basic member information in a class, and "set" to change it. For example, getName() may return the name of an object and setName() would change it.

 


3. Testing

For each project, you will describe how you tested your program. There are 3 areas on which for you to focus:

  1. Normal function - tests you run to make sure that your program works as advertised
  2. Boundary cases - test the boundary cases where the smallest and largest acceptable values are tried
  3. Error cases - test that your program responds to bad input by issuing a reasonable error message