Hide menu

TDDD33 Programming (C++)

Correction Guide

This page contain things that may be checked when we correct labs. Make sure you check yourself before demonstrating. Check the lab-instruction for information on how to demonstrate.

Grading of labs

  • Pass. The lab is finished to our satisfaction.
  • Returned. Your solution have issues that need to be corrected.

Is the submission complete?

Does it follow available instructions how to demonstrate or hand in?
See the "lab instructions" for information.

Do the code follow correct C++ syntax?

Make sure to always compile with all options outlined on the "Compilation" page in the menu to left.

Does the compiler produce errors during compilation?
Correct your code to remove the error. Remember that implementation files (*.cc) are compiled and header files (*.h) are included (#include). Never write header files on the command line. Make sure to remove any *.gch files.
Does the compiler produce warnings during compilation?
Correct the code to avoid the warning or add a comment explaining why you can ignore the warning. Many warnings are important and indicate real errors.

Is the code well formatted?

See the "Brief style guide" in menu to left. Be warned that your supervisor will spot any formatting errors at a glance.

Does it use correct and consistent indentation?
Use Tab while you code. Remember that emacs can indent all your code (M-< C-Space M-> M-x indent-region).
Do you use spaces around operators to clearer code?
If you add spaces around operators, and align corresponding operators on consecutive and similar lines the code becomes clearer and easier to read.
Do you group strongly related lines of code in sections, and separate the sections with empty lines to get clearer code?
Use blank lines to separate code sections with different objective and use comments to describe the objective of each section.
Do you split long lines (80 characters or more) at suitable places to avoid automatic line breaks?
Emacs, terminals and printer-tools use lines of 80 characters by default. If your lines are longer they will be automatically wrapped which effectively destroys your indentation and makes the code harder to read and follow. Sometimes the lines are even truncated so the ending of long lines are lost! Manually wrap and indent your long lines!
Did you remove any DOS line breaks (appearing as ^M on printouts)?
If you work at home or in windows DOS line breaks are often used. They conflict with the compiler and tools, and yield unreadable printouts (with a lot of ^M). Remove DOS line-breaks with the dos2unix terminal command (dos2unix file_with_dos_lines output_file)

Did you follow the instruction?

Do your solution include all requested features?
Read the instruction again to verify you did not forget some feature.
Does every feature behave as outlined in the instruction or examples?
Read the instruction again to verify all features behave as we expect.

Is the code easy readable?

See the "Brief style guide" in menu to left.

Do you use descriptive variable names?
Name variables to indicate what you sore in them. This will help you to find bugs, and will help any reader of the code to easily understand how it works.
Do you use descriptive function names?
function name shall indicate what the function do - everything the function do. Only do "one thing" in each function too keep the name short and clear, and to keep the function reusable by other code.
Do you use a consistent naming scheme to differentiate local variables, constants, classes, functions and member functions?
It should be immediately clear from the name whether it is for example a constant variable or a normal local variable. Constants are normally written with VERSALS.
Do you include relevant comments?
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. Keeping functions at a size less than 20 lines helps greatly in understanding and overview when reading the code and searching for problems. If some program do not fin on one screen, split it in several functions.

Is the code well structured?

Do you use non-constant global variables?
We will not approve your solutions if you use global variables.
Do you use suitable functions?
Functions should perform one task only, they should have suitable parameters, suitable return values and descriptive 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 not be approved.
Do you use a generic solution?
Your solutions must be one algorithm that handle all cases. Solutions that have one if- or case- for each possible input or example is called "complete enumeration (of all cases)" and is never approved. To produce precomputed result for every case is not even considered an algorithm by us. Also remember that any case shall be handled, not just cases presented in examples.
Do you use one piece of code to cover each case?
You are not allowed to. Write one generic piece of code that cover all (or most) cases to the extent possible. Solutions with a long list of if-statements never be approved. (But it may be good as an intermediate solution, to better see how the code should be reworked to something generic.) If you find yourself in need of many (about 5) if-statements you should think if you can solve the problem with a loop, with recursion or something else more 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 not be approved. You should for example not use language constructs such as "continue" or "goto", you should never modify the loop variable of a "for"-loop, you shall store data in appropriate data-types, etc.
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.
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. If for example you want to modify one item in a list, do not do everything in the loop to find the item. Instead, find the item first, and modify the found item after the loop.

Is the code correct in all cases?

Does it handle (if requested) all unexpected input?
Check carefully to the instruction, and to what you would expect if you are the user of that program.
Can any array index or similar be out of bound?
If your code allows any possibility (however unlikely) that an invalid array-index is accessed we will not approve the program. This error will sometimes produce "segmentation fault", but far from always. Most of the time the program seems to work, even when the faulty index is accessed.
Is all dynamically allocated memory correctly released in all cases?
We consider all memory leaks are very bad. It does not matter that the leak only happens once just before the program exits. You shall release (delete) all memory you allocate (new).

Page responsible: Klas Arvidsson
Last updated: 2013-08-12