91ÖÆƬ³§

Programming and Documentation Style Requirements

Here is a list of four categories of documentation to be considered:

1. “External” Documentation:In programming classes, the comprehensive set of documents that detail the design, development, and structure of a program are usually condensed into a comparatively brief ‘block comment’ at the top of the source code. This “external” documentation will minimally include:
   1. Your name, the course name/number, assignment name/number, instructor’s name, and due date.
   2. Detailed description of the problem the program was written to solve, including the techniques (e.g., algorithms) used to solve the problem.
   3. The program’s operational requirements: Which language system you used, special compilation information, where the input can be located on disk, etc.
   4. Required features of the assignment that you were not able to include, and/or information about bugs that are still known to exist.

1. Class Documentation:When writing a class in an object–oriented programming language, it should be preceded by a block comment minimally containing the following:
   1. The name of the class, your name, the names of any external packages upon which your class depends, the name of the package of classes containing this class (if any), and inheritance information.
   2. An explanation of purpose of the class.
   3. Names and very brief descriptions of the class and instance constants and variables.
   4. Names and very brief descriptions of constructors as well as the implemented class and instance methods.

• Internal Documentation:The details of the program are explained by comments placed within the code. The internal documentation should minimally include the following:
  1. A ‘block comment’ should be placed at the head of every method (a.k.a., function or subprogram). This will include the method name; the purpose of the method; the method’s pre– and post–conditions; the method’s return value (if any); and a list of all parameters, including direction of information transfer (into this method, out from the method back to the calling method, or both), and their purposes.
  2. Meaningful identifier names. In a nod to tradition, simple loop variables may have single letter variable names, but all others should be meaningful. Never use nonstandard abbreviations. If your language has accepted naming conventions, learn and follow them.
  3. Each variable and constant must have a brief comment next to its declaration that explains its purpose. This applies to all variables, as well as to fields of structure declarations.
  4. Complex sections of code and any other parts of the program that need some explanation should have comments just ahead of them or embedded in them.

1. Miscellaneous Requirements:
   1. Write programs with appropriate modularity; that is, create classes when appropriate, write methods that accomplish limited, well-defined tasks, etc.
   2. Global/public variables should never be used in your programs for my classes unless I have approved their use for your particular situation.
   3. Be generous with your use of “white space” (blank lines) to set off logically related sections of code.
   4. Indent bodies of methods, loops and IF statements, and do so with a single, consistent style.
   5. Like global variables, unconditional branching (e.g., goto) may not be used in your programs unless I have approved its use for your particular situation.

If the program is written in Java, the recommendation is to use Javadoc comments (that is, using /** … */) instead of traditional comments, and generate the Javadoc page to be used. 

If there is a choice between writing code that runs quickly and writing code that is easy to understand, make it easy to understand. Never pursue efficiency at the expense of clarity. We conclude by writing this: “Structure and document your program the way you wish other programmers would theirs.”

References

1. O. McCann. “Toward Developing Good Programming Style”.  [accessed on November 11, 2011]
2. ***, A beginner’s guide to writing documentation.. [accessed on September 17, 2017]