Non Programming Grading

Non-programming courses and assignments (essays, written assignments, problem-solving, etc.) grading standards will be detailed within the courses and assignments. In general, you can expect grading to be based on logic, accuracy, and adherence to specifications. Good writing practice, style, grammar, spelling, and organization will also apply. You will be held to competent college-level writing standards. Handwritten, poorly organized, or sloppy work will not be accepted. Cell phone photos of work, images, or diagrams will not be accepted.

Programming Grading

Program grading is holistic and based on multiple factors including correctness, adherence to specifications, good programming practice, style, modularity, architecture, robustness, elegance, and accuracy. The following grading system will be applied to all programming assignments in programming courses, including machine learning courses, unless otherwise specified. Grades will typically be 100, 95, 90, 85, etc. based on the following specifications.

• A 100: No errors detected.
• A 95: Your code is excellent, conforms exactly to instructions/specifications. Any problems are minor and would only require a small “tweak” to achieve 100. A "tweak" is one line, one name, one parameter, etc.
• B 85: Your code is above average, conforms by far to the majority of instructions/specifications. Problems are significant but easily fixable. Fixes would require more than a "tweak" but less than a complete rewrite of any complete section of code. For example, multiple occurrences of using incorrect loops or more than one return per function.
• C 75: Your code is average, conforms to most instructions/specifications. Problems are substantial and would require some effort to correct. Fixes would require rewriting whole sections of code, or correcting three or more mistakes, but not a complete rewrite of most of the code.
• D 65: Your code is below average, conforms to few instructions/specifications. Problems are substantial, and would likely require a complete rewrite of most of the code.
• F 50: Your code is well below average, conforms to few instructions/specifications. Code essentially "runs" and resembles what was requested, but has major flaws. Problems are substantial and will require a majority or complete rewrite of most of the code.
• F 0: See below.
  

Partial credit may be given within the ranges above based on the instructor's discretion. For example, a score of 88 may be given for work that is between a 90 and an 85.

Automatic Zero

Course are conducted as close to professional standards as possible while allowing for an academic environment. In a professional environment simple correctness is not enough, and it will not enough here. Code submission must meet the required process and formatting standards or they will not be accepted for grading. Violation of any requirement below = automatic zero. In industry, repeated violations get your work rejected and eventually get you fired. Here, repeated violations will cause you to fail assignments—and possibly the course.

• Failure to include a file comment header exactly as instructed.
• Failure to document/comment functions and methods exactly as instructed.
• Failure to include a proper README or proper .gitignore
• Failure to produce output exactly as examples or specifications dictate.
• Incorrectly structured project, including misnamed files, or using directories not specified in the assignment.
• More than three violations of any best practices.
• Failure to submit properly as instructed. This includes all the following:
  • Any stray files in your repo.
  • Submitting zip files not as directed or with stray files/directories.
  • Submitting incorrect links. Use the web URL, not the SSH or .git link.
• Failure to use your repo properly. This means you must commit often, small, smart.
• Failure to compile/interpret without warning and/or error for any reason.
• Failure to run on Linux will be rejected. See FAQs for why.

Why automatic zero at all?

If you review the “automatic zero” list, each item has two things in common: it is trivially avoidable (you have a checklist) and it is essential professional behavior.

Example: submitting the correct assignment link. This is a simple copy/paste plus a quick verification—seconds of work. In a real job, getting something that basic wrong can mean delivering the wrong product, losing trust, and being terminated. The link itself isn’t the point; attention to detail is. Every item on the list tests the same skill: consistent, basic competence. If you can't or won’t perform simple checks, you are not operating at the level demanded by this discipline and profession, and your grade will reflect that.

General Grading Philosophy

Just because it runs doesn’t mean it earns a good grade. Your grade reflects modularity, architecture, style, clarity/elegance, sound practices, robustness, correctness, and adherence to instructions. “It works” by itself is worth little. “It works and is well-designed, maintainable, and built to standard” is what earns high marks.

You are not training to produce code that merely functions. You are training to write clean, maintainable, professional software—and to think with the discipline of an engineer and computer scientist.

An academic analogy: Imagine you are in a writing class. You are told to write a story about your last vacation, it has to be 2,000 words or more, and you are given specific guidelines on how to format your story and submit it (e.g. typed, double-spaced, 1" margins, etc.). Imagine you write that story, and you very accurately describe your vacation, but you have spelling errors, grammar errors, run-on sentences, inconsistent and poor formatting, you only wrote 800 words, and you submit it handwritten on the back of 270 bubble gum wrappers. Despite the fact you accurately described your vacation, your assignment will fail, and you should expect it to. You would not be able to credibly argue; "But I wrote about what I did on vacation!" Obviously the point of such an assignment in a writing class is not to explain your vacation, but rather to learn and demonstrate proper writing techniques and discipline.

That is how you need to think of learning to program. You are not learning programming. You are learning computer science, engineering, computational thinking, logic, and discipline. The programming itself is simply a demonstration of those concepts.

A real-world analogy: Suppose you order a ham sandwich at a restaurant, and you want it with mustard on wheat bread. Then you get a ham sandwich with mayonnaise on white bread. When you complain and the waiter says, "Hey, it's a ham sandwich! You got what you ordered! I ate one just like that yesterday, and it worked for me!" Would you accept that answer? No. Why? Because the waiter did not adhere to your specifications. The fact that you got a version of a ham sandwich which "worked" for someone else is worthless to you because it's not the version you specified. It might be the most perfect, beautiful ham sandwich with mayonnaise on white bread in the Universe, but it's worth exactly ZERO to you because it did not adhere to your specifications.

"It works" is worth nothing.

It works and it is done right is worth everything.