Dr. J’s Coding Standards

Students are expected to familiarize themselves with the Unix operating system. Some Unix fundamentals necessary for class may be covered during the first couple of weeks of classes (perhaps in the lab sessions); hence, it is your responsibility to know if this is available, particularly if you feel you need this information.You may go to http://accounts.ecst.csuchico.edu/ to either create a new account or to update an existing account. Students must take responsibility in honing their computing skills and in gaining valuable experience functioning within both the personal computing and multi-user platforms.

During the first couple of weeks in class/lab, you will be given explicit instructions on how to submit your source code electronically. All source code connected to a programming assignment must be submitted electronically by the due date and time in order to receive ANY credit points; late submissions will not be accepted. 

1. All projects must be accompanied by a working Makefile.
2. Code should conform to the Google C++ Style Guide described in http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
3. Code should be neat and readable, with consistent indentation and proper use of whitespace.
4. Files must be organized in accordance with standard conventions.
• In C++, split code appropriately among header and source files, and use #include in the proper places, and #ifndef to avoid multiple inclusion.
5. Code should not perform any actions visible to the client code or the user, other than those in its specification.
• In particular, avoid debugging printout in the turned-in version of your code.
6. Appropriate use should be made of language constructs that deny privileges.
• In C++: Use const, private, etc.
7. Sample source code:
   • C++: RedBlackTree.h, RedBlackTree.cpp (see Doxygen-generated documentation and source listing)

1. All source code must be written in the programming language the professor requires for the class.
• In C++, stay as close as possible to the C++ 1998 ANSI standard.
2. At the beginning of every file should be a comment indicating the file’s name, author, date, and purpose.
• Note: The purpose comment does not have to be very long. If your code is well-organized, then something like “Header for class Foo” is generally fine.
3. Be sure to check the Google C++ Style Guide regarding comments in your code; in particular, the file, class, function, and variable comments.
4. Only required headers should be included.
• In C++, avoid the “.h” system headers; for example, use #include<cstdlib> instead of #include<stdlib.h>.
  

1. It is your responsibility to guarantee that your electronic submissions are complete and includes all the necessary (source, header, README, and Makefile) files to successfully compile and run/test your programs.
1. Projects that do not have a working Makefile included in the submission will not receive any credit - no exceptions.
2. All submissions must come with a README file that contains
   1. specific notes regarding your submission (e.g. what features work, what features do not work, any additional functionality you incorporated, etc.); and
   2. a sample typescript (generated with the Unix script command) of your successful compilation of your submission, followed by at least one run of your compiled program.
   Note: Projects that do not have a README file included in the submission will not receive any credit - no exceptions.
3. Electronic submissions should not include any binaries (executables, object files, a.out files, core dumps, etc.). 
2. Projects that do not compile successfully will receive a maximum possible 50% credit. The instructor/grader reserves the right to award no credit to such submissions. (Hence, if you are having difficulty getting a portion of your code to compile, it is in your best interest to comment out this section and leave the code intact with sufficient documentation so you have proof that you were attempting to get it to work.)
3. Projects that crash during runtime will receive a maximum possible 80% credit. (Again, comment out incomplete code and document it. If you were unsuccessful in implementing a required feature, be sure an appropriate message is displayed informing the user of this situation.)
4. Students are expected to include a README file with their submissions if they have any assumptions, specific instructions, notes, etc. they want to leave the instructor/grader regarding their submission.
5. The department has an approved set of rubrics used when evaluating student work (see http://csci.ecst.csuchico.edu/assessment/rubrics). In particular, the Programming Project rubric will be used when evaluating programming assignments submitted as part of requirements in a course.
6. When the instructor uses BB Vista for maintaining student grades, a simpler version of the rubric such as the following may be used to evaluate programming assignments (click image to see a larger view):
   
   
   
   
   
   Note: This rubric is only meant as a guide to maintain uniformity in evaluating programming assignments (and to provide consistent comments about the evaluation). The instructor/grader reserves the right to override the score calculated by the grading form.

1. Collaborative work of any form is strictly prohibited. You are assumed to turn in your own work and not the work of another person nor a group of people, unless otherwise specifically allowed by the Instructor. Other than the Instructor of this class and any teaching assistant(s) working with the Instructor, Students are expected to restrict seeking help from any additional individuals, except
   1. those officially listed as tutors in the “Tutoring Services” section under the Computer Science website at http://csci.ecst.csuchico.edu/facilities
   2. students can talk among themselves at the algorithm level; implementation discussions must be restricted to natural languages (e.g. English) - discussions that center around implementation/programming languages (e.g. C++) are not allowed
2. Do not cheat! Do not copy others work! Learn the material. The benefit and enjoyment you will receive will be much more valuable than any consequences of cheating. Dr. J will use electronic means to detect plagiarism/collaboration (e.g. MOSS; see a sample of MOSS output here) to check for cheaters on every assignment! Individuals who misrepresent work as being their own or who have assisted another will receive, on the first offense, a minimum penalty of a grade of zero on that assignment and a decrease of one letter grade on their final course grade. On succeeding offenses, students will get the minimum penalty of a final grade of F in the course and a memo concerning this included in their academic folder. The Dean of the student’s major may also be notified with the recommendation of expulsion from the University.
3. Dr. J reports all suspected violations of academic integrity to Student Judicial Affairs. Please refer to the University Policies and Academic Policies and Regulations, as written in the University Catalog, for more information regarding CSU Chico’s Code of Student Rights and Responsibilities (CSUC EM 08-40). Students are also expected to be aware of CSU Chico’s Policy on Use of Computing and Communications Technology (CSUC EM 07-01). Ignorance of these Guidelines is no excuse!