• Unless otherwise assigned, all programming is to be done individually. Discussion of approaches and algorithms and examination of sample code is encouraged, but when you sit down to write code it had better be your own. Infractions of this nature will be dealt with harshly. A first offense will get you a zero on the programming assignment and a warning. A second offense will get you an F in the course and will involve the Chair, Dean, and Student Judicial Affairs.

• Your code must compile for me to grade it. Code that does not compile will receive a zero. In addition, I will make clear what platform I will be using to compile and execute your program. It is your responsibility to make sure that your code will compile and execute correctly on the specified platform.
  
  
• You are expected to design before you start coding, utilizing the principles of object-oriented design. If you are required to turn in your design, it should be documented using UML. A typical design will provide detailed class diagrams, document class relationships, and if your application is modal, will include sequence diagrams. Here are two resources on UML:
  • UML Reference Card
  • UML Tutorial
    
    
• Your program must be readable and readily understood.
  • Design Issues
    • Starting with a clean design will greatly enhance the clarity of your program.
    • If you aren't sure how to represent the problem using classes, come to office hours and get help!
    • No public variables in classes, except constants as needed
  • Comments
    • Every file should have a comment header describing who wrote the program and what is in the file.
    • Every method or function should have a comment header describing inputs, outputs, and what it does
    • Develop a professional and consistent documentation format.
    • Inline comments should be utilized as necessary (but not overused) to make algorithms clear to the reader.
  • Formatting
    • Code should be indented appropriately and consistently to illuminate the program structure.
    • Do not use tabs in your source files - either use spaces or get an editor that will convert tabs to spaces.
    • No lines over 80 characters in length - break lines in a manner that enhances readability.
  • Use accepted naming conventions for types, variables, and methods:
    • Classes (types) begin with an uppercase letter and do not contain underscores: MyClassName.
    • Variables and methods begin with a lowercase letter and do not contain underscores: myVariableName.
    • Constants are all uppercase and words are separated by underscores: MY_CONSTANT_NAME.
  • C++ specific
    • No code in .h files except for small inline functions (two lines max).
    • One class per file pair - class declaration in .h, function definitions in .cpp or .cc.
  • Want more information?
    • here is a pretty good C++ Coding Style Guide
    • here are Sun's Code Conventions for Java
      

Academic Honesty

• If you make use of code that someone else has written (verify with me first that this is OK in any given circumstance), credit must be given in a way that makes it extremely apparent which parts of the code you wrote, and which parts of the code you didn't write. You must give credit to the author of the code you didn't write and supply a complete reference in both the file header and the class or method header.

• If you implement an algorithm conceived by someone else and described in a textbook, journal article, or web-based document, you must give credit for the algorithm where it is due and supply a complete reference in both the file header and the class or method header.