1. For any code file that you have written or modified, your full name must go in a /** ... */ "header comment" at the top of each code file (# comment for a Makefile). The StudentID# is not requested on code submissions---while it is required on hardcopy submissions and exams.
2. Instructor-provided files that you do not modify may be left as-is.
3. Any source other than instructor(s) must be acknowledged in the header comment.
4. Lines shall fit within 80 columns, except for the occasional jawbreaker namespace-qualified templated iterator operator application...
5. Indentation shall be consistent. Use a 3-5 space indent.
6. Files should not contain tabs---they are non-portable. (You can set most IDEs to convert indent tabs to 3 or 4 spaces.)
7. Long interior blocks shall have a comment on the closing "}" identifying keyword(s) on the line with the corresponding "{".

Guidelines that are not mandated:

• AOK to use the "C" underscore_convention or the "Java" camelHumpCase convention. [KWR uses the latter in his own examples.]
• AOK to put opening "{" at the ends of lines, with the closing "}" lining up with the start of that line, and to use the "} else {" and "} else if {" convention. [Text and KWR do this, which helps 40-line examples fit on one screen, but can make longer dense code look crowded.]
• Alternatively, line the braces up vertically, with lots of blank lines outside them too.
• AOK to use any of these conventions for naming class fields bar:
  • Just call it bar---any sign of confusion with a local variable in a method body means your method body itself is too big, or maybe your class is.
  • Call it bar, but refer as this->bar, much as with this.bar in Java. [KWR: I like this, but find it hard to remember this-> consistently, since the C++ compiler doesn't care.]
  • Underscore convention: _bar.
  • "Hungarian" suffix convention, e.g. append "f" for field, "p" for pointer etc. (Oh wait---that makes this barf.)