As per the syllabus, you can discuss the problem with classmates at a high level, but you can’t share code. All work turned in must be strictly your own. Also don’t reverse-engineer my solutions (even though they are obfuscated).
You should document what isn’t obvious from the code. That usually means saying not what something does, but why it’s there and how it fits into the overall program. Line by line documentation is not necessary, but certainly every function needs some explanation.
Try to put yourself in my shoes, or the shoes of someone reading your code who doesn’t know what the program is supposed to do or how it’s supposed to work.
For identification purposes, every program must have the author’s name and the assignment name or number at the top.
Note that I have deliberately not demonstrated good documentation in the example programs because we will study them to determine what they do and how they work. You are encouraged to document your own copy as a way to help your understanding.
All work should be turned in via the appropriate dropbox on blackboard.
Programming problems will be turned in by submitting the URL of your codepen. Do not change your code after the deadline.
Non-programming problems should be turned in as documents (word, PDF, etc). If you want to draw something by hand, take a picture of it and submit the picture. Apps like Adobe Scan will make a reasonable approximation of a scan from a photo and generate a PDF.
All homeworks should be turned in via blackboard at least 30 minutes prior to the beginning of the corresponding class period. Homeworks turned in late will be penalized 10% for each day or fraction of a day they are late. For example, an assignment that is turned in one day and one hour after the deadline and would have received a 90% will instead receive an 70% since it is more than one day late.
Computer programs are not solely about getting stuff to work. They are largely about that, but not solely. It’s also important for them to be clear and readable, because no one will want to use your code if they don’t feel they can understand and maintain it.
For now, let the following list of rules and guidelines suffice:
Good coding avoids redundancy and unnecessary duplication of code. This is sometimes known as the Don’t Repeat Yourself (DRY) principle. While it can obviously be overdone, avoiding repetition means:
For example, if you often need to zark some data, defining a function to
zark the data and invoking it whenever necessary means that you can debug the
zark function once, and if the requirements of the zark operation change,
you can update the one function to effect the change. So, we’ll add one more
rule: Avoid redundancy!