TDDD33 Programming (C++)

Correction Guide

This page contain a "protocol" describing the steps performed when a lab is corrected, and how detected errors are handled. Labs are pass or fail, so it is of utmost importance that you check your lab solutions to this protocol before demonstration. If your lab fail all your work is in vain.

See the "lab demonstration" page for rules regarding demonstration. You can demonstrate in two ways: show the solution to your supervisor during lab time or submit your solution to the supervisor (on both paper and email).

Grading of labs

• Pass is the grade if everything is OK.
• Fail will you receive if you made errors or did not follow the instruction. The lab is lost, you will have to be more careful next lab.
• Returned is not really a grade. If it is evident you made everything within your power to follow the instruction and to detect and fix all errors, then you may get one chance to correct the lab and hand it in again.

Is the submission complete?

Does it follow available instructions how to demonstrate or hand in?

See the "lab instructions" for information. If you do not follow instructions carefully the lab will fail.

Do the code follow correct C++ syntax?

Make sure to always compile with the options -Wextra -std=c++98.

Does the compiler produce errors during compilation?

No excuses. The lab will fail.

Does the compiler produce warnings during compilation?

If you did not explain in a comment why the warning can be ignored, the lab will fail.

Is the code well formatted?

Be warned that your supervisor will spot any formatting errors at a glance.

Does it use correct and consistent indentation?

Indentation need to be 98% correct to pass. See the "style guide" page.

Do you use spaces around operators to clearer code?

If the code is too compact we can not read it, and the lab fail. See the "style guide" page.

Do you group strongly related lines of code in sections, and separate the sections with empty lines to get clearer code?

If the code is too compact we can not read it, and the lab fail. See the "style guide" page.

Do you split long lines (80 characters or more) at suitable places to avoid automatic line breaks?

If the next line is obscured by the continuation of the current line we can not read your code, and the lab fail. See the "style guide" page.

Did you remove any DOS line breaks (appearing as ^M on printouts)?

DOS line breaks may conflict with the compiler and tools, and yield completely unreadable printouts. Remove them with dos2unix, or the lab will fail. Since in this case you worked at home, do not ask, or you will be "detected". Working at home is only allowed if you do not need help to do it (See "Important" page).

Did you follow the instruction?

Do your solution include all requested features?

If something is missing the lab will fail.

Does every feature behave as outlined in the instruction or examples?

If something do not work the lab will fail, or in minor cases be returned.

Is the code easy readable?

Do you use descriptive variable names?

See "style guide". If you use abbreviations or "anonymous" names on variables your lab may fail. Naming variables good is very difficult, but lack of effort will not be accepted.

Do you use descriptive function names?

See "style guide". A function name should indicate what the function do - everything the function do. Only do "one thing" in each function too keep the name short and clear. Naming functions good is very difficult, but lack of effort will not be accepted.

Do you use a consistent naming scheme to differentiate local variables, constants, classes, functions and member functions?

See "style guide". It should be immediately clear from the name whether it is for example a constant variable or a normal local variable.

Do you include relevant comments?

See "style guide". Despite good variable and function names it is sometimes not immediately clear from the code itself what it do. Then you must include a comment to explain. A description of every function is specially important.

Did you remove all old and unnecessary code?

Never write code you do not need. Beginners often cover the same case two or three times without thinking, or keep old code commented out. Put old code in some "junk" file if you want to keep it, and think of what the code you write do, and which cases it cover to avoid unnecessary code. In serious cases the lab may fail.

Is the code well structured?

Do you use non-constant global variables?

If you do the code is returned.

Do you use suitable functions?

Functions should perform one task only, they should have suitable parameters, suitable return values and suitable names. No function should contain excessive amounts of code. If it do not fit in its entirety with space to spare on screen (with lines of 80 characters) it is definitely to large. Split in smaller functions or use another algorithm. Most labs can be written in 60 lines or less of well formatted code. Excessively long solutions will be returned.

Do you use a generic solution?

Your solutions must handle all cases, not just any particular case outlined in an example. If you do not your lab may be returned or fail

Do you use one piece of code to cover each case?

You are not allowed to. Write one generic piece of code to cover all (or most) cases to the extent possible. Labs with a long list of if-statements will be returned. (It may be good as an intermediate solution, to better see how the code should be reworked to something generic.)

Do you use language features relevant for the problem?

Solutions that misuse language features or use a "weird" solution for the problem at hand will be returned.

Do you use loops suitable for the task at hand?

Use "for" loops when you know (easily can calculate) the number of iteration. Use "while" when you need some iterations to determine when to stop. Use "do" if a "while" loop should always be done at least once. Weird solution may be returned or in serious cases failed.

Do you do one thing at a time, step by step?

Do not use one big construct to do "all" work. Split the work in many smaller constructs and do them sequentially. Weird solution may be returned or in serious cases failed.

Is the code correct in all cases?

Does it handle (if requested) all unexpected input?

If not (and requested), the lab will be returned or fail

Can any array index or similar be out of bound?

This will sometimes produce "segmentation fault", but far from always. If index checks are missing the lab will fail or in minor cases be returned.

Is all dynamically allocated memory correctly released in all cases?

Memory leaks are very bad. Your lab will be returned or fail.

Page responsible: Klas Arvidsson
Last updated: 2010-08-21