UNIVERSITY OF WISCONSIN-MADISON
Computer Sciences Department
CS 537
Fall 2020
Barton Miller
CS 537 Coding Standards

When you write your programs for CS537, there are some important things that you must do to make your program clear and well-structured. These things contribute to cleared code, safer and more reliable code, and easier maintenance in the future. In the real world, most companies (certainly the good ones) are quite serious about such coding standards.

Half of the grade for most programming assignments will be based on structure and code quality, so please do pay attention to this list.

  1. Check the return value of all system and library calls.

  2. Always indent when statements are part of a control-flow statement such as "if" or "while". Choose a reasonable number of characters (such as 3 or 4) and make sure that you indent consistently.

  3. There should be no constants other than, perhaps, zero or one, in your code. Any constant values should be defined as using a "const" declaration.

  4. Global variables are a really bad idea, in general. If you think that you need one, please come and talk with Bart. Non-const global variables are not acceptable in your program without prior permission.

  5. Comments:

  6. You must use a "makefile" for your program. The default rule should build the whole program. You also need to have a "clean" rule that removes all .o and executable files.

  7. You can use (and are strongly encouraged to use) standard Linux library functions.

  8. Including someone else's code in your program without citing the source of that code is plagiarism. This would be a serious occurrence of academic misconduct. Including someone else's code in your program also requires that the code is labeled with the permission to do so. Code with no copyright markings or permissions is not public or open source; it is poorly labeled private code to which you have no usage rights. If you want to include someone else's code in your program, please come talk with Bart or a TA first.

  9. Key to any good program, and a key to making your implementation life easier, is having a clean, modular design. With such a design, your code will be simpler, smaller, easier to debug, and (most important, perhaps) you will get full points. You will need to develop clean interfaces for each component. And, of course, each component will be in a separately compiled file, linked together as the final step. And, again of course, you will have a makefile that control the building (compiling and linking) of your code. Be careful of going to the other extreme: one function per file is not good structure.


Last modified: Wed Sep 2 10:50:10 CDT 2020 by bart