How we rate

We assume a perfect score. The more (severe) flaws we find in your code, the more we reduce the score. Per exercise, the rating is on a coarse scale: full point ('1'), half ('?') or none ('0').
It doesn't take many flaws to take a point off your exercise score. So please hand in highly polished solutions.

Why we are so demanding

In order to give the programmer full control, C++ allows some dangerous practices. We want to produce programmers who habitually apply good practices, so as to avoid the pitfalls. In our experience, the best way to do that is to require such good practices.
As a result, it does happen that students spend a lot of effort but still score zero points. We sympathize with the disheartened student, but we won't lower the standards.
We'd much rather award points though, and we'd like to help you improve. So please come to us with your questions: we will try to help.
If you disagree with us and want to contest a general rule, please contact us to tell us why. If you think your solution in a particular case should be allowed to violate a rule, please mention it in a comment. Argued deviations from the rule indicate that you've thought about it. In that case, we're often more lenient. Do be prepared to argue though, in either case.
Ultimately, it's not even our goal that you apply our rules forever, just that you become aware that at every point where they apply there's a small decision to be made. We hope that eventually, after the course, you'll be able to come up with your own set of rules.

Categories

Some flaws are so common we have abbreviations for them. These abbreviations pertain to several aspects of the program. Here are those aspects, and the reasons we think they're important. Please be aware that there are tradeoffs though.

Operation

The program should work. Issues in this category are often severe.

integrity

The program should run under all circumstances. Even if it cannot perform as requested, it should tell the user and the operating system so, and stop in an orderly fashion. In order to run, it should be compiled in the first place.

correctness

The program should act as promised/required by the exercise. To avoid spending 90% of your time checking for correct input, you may however assume that input is correctly formatted.

efficiency

The program should use resources sparingly, first and foremost at run time but also at at compile time.

Maintainability

It should be 'easy' for a programmer to resume work on the program at a later time, e.g. to fix or extend it. It's the programmer's job to express their thoughts in code as clearly as they can. (It's the compiler's job to convert that code to an efficient program.)

structure

Software is best built in reusable blocks - functions, classes... Each block should accomplish one task. The clearer the boundaries between the blocks, the better.

clarity

The intention of the programmer should be clear with each expression, statement, function, class.

robustness

It is a good thing to protect against future and current mistakes.

Style

Style does matter. Good style enhances clarity. Consistent style causes fewer surprises, and it makes purposeful deviations stand out more.

layout

Indentation, placement of opening/closing of sections of code and other use of whitespace all contribute to the readability of the code. Please use our layout rules, even if you have good arguments for yours. We make more mistakes when we have to switch styles a lot. Ultimately, the quality of the feedback you receive suffers.

consistency

If nothing else, at least be consistent in your style. If possible, stick to conventions so you're even consistent with others' style.

Severities

The higher the number, the more severe the flaw. The scale runs from 1 up to 5.

Graph

Abbreviations

This clickable svg representation shows the abbreviations by category.
More good advice is in the Hints and Tips.