Mark criteria

The following list compiles the main criteria used for marking projects.

Consult the relevant course pages for information about lateness, missing projects, plagiarism, etc.


In the report, you are asked to
  • Present pseudo-code
  • Analyze complexities
  • Answer questions
  • Present results and analyze them
When you are asked to analyze something, it is not sufficient to spot it and describe it. We expect you to come up with an explanation of the reasons why phenomenon occurs.
Plagiarism is heavily sanctionned at the ULiege. Note that all projects will be submitted to plagiarism detection (both code and report) !
Although how you present your results is not a criterion in itself, it usually plays an important role on how well your ideas are understood. A good report should convey efficiently the right information. Aside correctness, this means:
  • Overall structure easy to follow --> follow the one we give you
  • Correct spelling and grammar: together, they ease the reading and the understanding
  • Clarity and concision; there is usually some elegance in simple yet efficient designs --> stick to the number of pages we indicate. Do not make tables of content.
  • Use an appealing formatting, or rather, do not use an ugly one --> use latex for the report and one of its algorithmic package for the pseudo-code (you can use the same one as the course's)
  • Regarding pseudo-code:
    • Provide a specification for every pseudo-code function you write! It is hard to grade code we do not understand...


The mark corresponding to the code are split into three main categories: correctness, language and style. We consider that writing good-quality code (language and style) is as important as writing correct code.

We will implement some automatic testing for most projects. With time we have noticed a few misconceptions regarding those:
  • Misleading feedback from the automatic testing cannot constitue any form of excuse/pretext. It might indeed happen that the tests are wrong. This usually (when it does) occurs at an early stage, when the testing scripts are not robust enough. Most of the time, however, the bug does lie in the student code. Before reporting an issue, ensure you cannot reproduce the error. Otherwise, report it and we will adapt as soon as possible.
  • The tests do not determine alone the mark you will get.
  • Not all tests are visible. We are encouraged you to develop your own tests. Thinking how to test a piece of a code is usually as formative as writing it.
  • If automatic testing is set up, we will make no exception regarding the critical mistakes; reading the feedback is enough to prevent such problems.
You will get a mark of 0 for the relevant part in the following event:
  • The submission is in a wrong format
  • Some files are missing/empty
  • There are some compilation errors
The following errors will be sanctionned (with respect to their frequencies)
  • Warnings at compile time --> use the additional flags to get all warnings when you develop your code
  • The code is not following the specification
  • The code does not work (segfault, infinite loop, etc.)
  • Illegal access to memory
  • Memory leaks
  • Non-acceptable slowness (e.g. wrong class of complexity)
Language refers to the correct utilization of the C language. The following errors will be sanctionned (with respect to their frequencies)
  • Useless or missing inclusion
  • Usage of global variables or macros
  • Missing static in signature of local functions
  • Badly structure code (e.g. monolithical code, uselessly complex code, avoidable redoundancy, etc.)
  • Uselessly limited code (e.g. size fixed at compile time)
  • Misplace variable declaration (e.g. declaring a variable far from where it is used, not following c99 conventions, etc.)
  • Inadequate type (e.g. int instead of size_t for array length or iterating variables, double instead of int, etc.)
  • Inadequate control structure (e.g. using while instead of for to iterate over an array, using for instead of whilewith a complex condition, using several if when a switch is more coherent, etc.)
  • Not using shortcuts (e.g. +=, ++, *(x) instance of x->, b==1 instead of b, not using ternary operator, etc.)
  • Not verifying output values (e.g. with malloc, fopen, etc.)
The following will be sanctionned (with respect to their frequencies)
  • Using non-informative names for variables, functions, etc. (except for the course algorithm)
  • Using non-conforme variable/function/structure names
  • Indenting inconsistently
  • Using inconsistent convention (spacing around operators, spacing in signatures, brackets layout, etc.)
  • Inappropriate use of comments


Commenting is an art (except it can be mastered, therefore it is more a skill than an art, but anyway, the point is that it is tricky). Too many and the code become unreadable. Too few and the code is incomprehensible.

The trick is to write comments intented at someone who knows the general context of the code (i.e. familiar with the concepts) but who has not written it. That's your classmates, colleagues, TA and ... you. When you come back to your code six months later, you will wish you had taken the time to write some comments.

All auxiliary functions must be specified. A good descriptive name already allows readrs to grasp what the function is intented to do. However, full specifications allow you to be more precise about the nature of inputs and output, and about their relationship. They also allow the programmer to catch some mistakes, when they are well made and used.

Aside from specifications, every sizeable/tricky part of code should be commented upon. They should prevent two questions:

  • What is this whole block supposed to do?
  • Why has the programmer written the code like that?
In other words, they make up for the lack of affordance of (some (part of)) code.

Here are a few references on the matter, if you want to dig it deeper:

Last modified on February 26 2018 10:40