Please follow these rules for writing computer programs. If you fail to follow these, you risk having your grade lowered, or even receiving a 0.
Do not plagiarize, unless you are willing to see an F on your transcript. Putting your name on someone else's work is plagiarism.
I expect your software to work correctly, regardless of whether anyone in the past has made such a requirement of you. Read the assignment carefully, and be sure that your program does what the assignment asks. If you do not understand the assignment, get clarification.
Programs must compile, and should compile without warnings. I will not grade a program that does not compile, and will grade you down for ignoring warnings. Turn warnings on when compiling.
Test your program thoroughly. Do not be lulled into a false sense of security because your program passes one or two very simple tests.
Do not try to write programs by only sitting in front of a computer and typing. Always use scratch paper, and draw pictures of your data structures. Hand simulate your functions.
Turn in all source files that are part of your program. Be sure that your name is in every one of your source files.
Programs must be well-indented, and must follow a clear and consistent indentation scheme. I will not grade a program with extremely poor indentation. Either set tab stops to every 8 characters or do not use tabs. (Otherwise I have to figure out what your tab setting is.) See the Unix expand command.
Provide a clear, precise and concise contract for every function. Use correct grammar and spelling in contracts. A contract should tell just what the function does without going into details on how it accomplishes its job or what tools it uses to accomplish its job. A contract should never discuss such details of the body as local variables, loops or program structure.
Use reasonable, descriptive names for things. Avoid variable names such as number that do not really tell you anything. For short functions, you can use short names such as k for some variables. But descriptive names are better. In no case should you use a name that is descriptive, but says the wrong thing, and so is misleading. If you have a variable holds the time of day, do not call it distanceToTheMoon.
Do not use global variables unless you have been given permission to do so. You may use global constants.
Use technical terms correctly in comments. If you use the words precondition and postcondition in your comments, be sure that your precondition and postcondition are genuinely assertions, not just more comments. Use truth in advertising. If you do not know what an assertion is, do not use the technical terms precondition and postcondition.
Avoid long lines. Keep lines no more than 80 characters long.
Avoid margin comments. Use paragraph comments instead. A few short margin comments, particularly describing variables, are acceptable, but do not rely on margin comments to describe what lines in your program do.
Do not link source files together by including a source module (.cc, etc.) in another source module. Include header files instead, and use a linker. Do not advertise anything in a header or interface file that should not be available to other modules unless you have a good reason for doing that.
NEVER turn in a program in a non-text format, such as Microsoft word, or with formatting tags such as html tags. I will not grade a program in a non-text format, and any such program receives an automatic 0.
Do not turn in a program that only runs under Windows, and especially do not turn in one that only runs on your computer. In particular, for C++ programs,
Avoid magic numbers embedded in your program. Do not write 48 for '0' in your program. Do not create arrays of fixed sizes that are awkward to change without very good justification. A rule of thumb is that if you see any number other than 0, 1 or occasionally 2 in your program anywhere other than in the definition of a constant, you are probably doing something wrong.