The following list compiles the main criteria used for marking projects.
Consult the relevant course pages for information about lateness, missing projects, plagiarism, etc.
- Present pseudo-code
- Analyze complexities
- Answer questions
- Present results and analyze them
- 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.
- 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.
- The submission is in a wrong format
- Some files are missing/empty
- There are some compilation errors
- 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)
- Useless or missing inclusion
- Usage of global variables or macros
staticin 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.
size_tfor array length or iterating variables,
- Inadequate control structure (e.g. using
forto iterate over an array, using
whilewith a complex condition, using several
switchis more coherent, etc.)
- Not using shortcuts (e.g.
b, not using ternary operator, etc.)
- Not verifying output values (e.g. with
- 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