PROGRAMMING STYLE GUIDELINES

All homework assignments must conform to the following guidelines.   Failure to follow this guidelines will result in a lowered grade!

 

  1. All files will begin with a header similar to the following:
  2. //----------------------------------------------------------------------
    //  DEVELOPMENT ENVIRONMENT: Most likely JBuilder University
    //  WHAT:
    //      Title.............A brief title for the program or function
    //      Description:
    //          An explanation of what the program is designed to do.
    //
    //  WHO:
    //      Author............Who wrote the code.
    //
    //  WHEN:
    //      Inception.........The date the code was started.
    //      Last changed......The date the code was last changed.
    //          by............Who changed the code last.
    //
    //  HOW:
    //      Input:
    //          What input is required for the code segment(s) do accomplish
    //          its task.  Include user input as well as any file or dbms.
    //
    //      Public Variables:
    //          What public variables are used in the code segment.
    //
    //      Output:
    //          What output does the code produce.
    //
    //      Notes:
    //          Any additional comments that will be informative.
    //
    //----------------------------------------------------------------

    otherwise a function will have a brief one line explanation of its purpose.

  3. Lines should be a maximum of 76 characters if line wrap in your email program is a problem.  It is up to the student to determine if this is an issue.  If homework assignments are turned in with errors generated due to email line wrap points will be deducted.
  4. Comments can use either the ANSI standard /* comment */ or the C++ // single line comment.
  5. All data objects (variables) use Hungarian notation and are mixed case.
  6. All program constants use all capital letters.
  7. All function names are mixed case and should be descriptive of what the function does.
  8. Closing braces are on their own lines aligned with the command that began the code segment. Opening braces may either be on there own line aligned as above or at the end of the line following the command.
  9. Document why, not what you are doing. Comments are just notes to yourself and others reminding you of what you did. It is almost always easier to document code than it is to figure out later what the author was trying to accomplish.
  10. Use blank lines whenever necessary to make the code more readable.
  11. Use the variables i, j, k, l, m and n as loop indexes only (primarily in for loops), and use them in order. Using this rule saves many hours of trying to figure out which index is changing faster. Avoid using these variables for any other purpose.
  12. Use parentheses liberally. When in doubt, use them. Then you can be sure in what order things will be done.
  13. Avoid the use of global variables whenever possible. If you must use them, be able to explain why.
  14. DO NOT USE THE goto statement unless absolutely necessary.  While it is very rarely useful, if I can think of a way around its use (and I almost always can) you loose points.
  15. Always correct all the problems that create compiler warning messages. The program may run without correcting them, however, the messages wouldn't be there if they were not important.
  16. Indent each code block one tab stop (3 or 4 spaces minimum) to make the code easier to read. This means that all global variables, preprocessor statements, function headers, and function prototypes will be on the left margin. All other code will be indented at least one tab because it is inside the function code block. Remember neatness counts.