Minimal Checklist and Associated Penalties
For details and rationale behind the following rules, see the
documents related to
"best practices" in this teaching module, e.g., for
These rules must be respected at all times, not just when showing/sending
me your program.
Therefore, penalties can apply any time I see thee rules
are not followed.
(-1/20 each time you are caught not following these rules)
- For screens big enough to view lines of 50 characters
with a text editor,
in a comfortable way:
2 and only 2 windows open on your screen: i) a text editor,
ii) a navigator for your other documents
(checklist, interface/results, documentation, search engine, ...).
Otherwise, using only 1 window is allowed.
- Lines must be less that 79 characters long and short enough for
not causing line wrappings (or characters to be invisible)
on your screen.
- The open windows must not overlap.
Reminder: to be efficient, you should
NOT have to regularly swap or scrop windows.
"Net" which is optional). Reminder: you work environment
must be ready when
the class teaching begins.
- The HTML tag for the title for your result window must contain your
- You must use a computer mouse, NOT the touchpad of your computer,
can show that when handling a text file you are as fast with
your touchpad as
I am with a computer mouse.
Indeed, statistically, you are wasting a lot of time by
- The programs must be directly executable.
E.g., they must not have any syntax error in them (such errors can always be
quickly found by the "code removal" based binary search explained
executable simply by clicking on their file name in an e-mail Web client.
Therefore, they must only import absolute files, not local files.
Before sending the e-mail, send it to you and test that the program
and executes well from a navigator called from your
Use "devoir" in the "Subject:" part of your e-mail.
(0/20 if the program cannot be directly executed).
- In a line comment before each required function, you must indicate
" //the next function implements all its required functionalities"
(or simply add "//@@@ works" at the end of the parameters)
or you must list all the functionalities that you have not implemented
(if you do not do so, not only you will not have the points
associated to each functionality,
you will have additional penalties)
If you do not implement at all a function,
in a comment give its name and
signature and indicate that you have not implemented it.
- The recommended information must be provided and the
conventions must be followed
(-1/20 per missing information or not respected convention),
- all the required information in the header should be provided
- each variable in the function signatures must be typed (using comments)
- each variable must be preceded by "var " and initialized before it is used
(when a function does not do anything and no syntax error is delivered,
it probably includes an un-declared/un-initialized variable or
it does not return anything).
- the type and content of each variable content from the signature or
given by the user must be validated before it is used
- "while" loops should have an associated line comment showing that they
are not infinite loops, unless this is already clear from the code
- in your program final version, there must be no trace outside the console
- the error messages must be explicit and give all the information that
the user needs to easily understand the error and where it comes from.
- The recommended structuring conventions must be followed, e.g.,
- no code (of more than 1 line) duplicated at different places
- no function with more than 20 lines or more than 2 loops
(+ try to adapt the scope of your functions for them to have only 1 loop).
Form (-1/20 each time you do not follow these rules)
- The recommended naming conventions (for
must be followed, e.g.:
- each name must be very explicit (-> better than comments), in the
recommended object-oriented style, in Intercap style, in correct
without abbreviations except for obvious or very common ones
- a file name must have an extension and must never include spaces
- a file name or the name of a local variable must begin by a lowercase
- the name of a global variable must begin by an uppercase
(in the case you really need a global variable; this is a very rare
- the name of a constant must be in uppercase
- the name of a boolean function must begin by "has"
- the name of a boolean variable must begin by "has"/"is"/"do"/"with"/"no"
- Indentation/spacing, alignments, line length, concision
- each instruction that is logically within another must be indented
with 2 spaces with respect to it (never use tabulation characters)
- each instruction that is not logically within another must not be indented
with respect to it
- in an If-Then-Else statement, the smaller block (of instructions)
must be given first
- there must be 1 space character after each "if"
- block delimiters must be aligned (vertically or horizontally)
- no line must have more than 78 characters
nor cause line wrappings (or characters to be invisible) on your screen
- write code in a concise way (to enable readers not to scroll and hence to
improve readability and understandability), e.g., fill the lines
do not use white lines within a function
- the assignment operator ('=') must not have a space before it
and must have one after it when this makes the assignment more readable
always except when this cause line wrapping and this is
optional in the
non-body part of a "for" loop),
- function definitions must have 1 space between the names and the parameters
and at least 1 space between the parameter;
function calls must not have these spaces (except for avoiding
- The other conventions recommended for readability and reusability
must be followed, e.g.:
- every instruction must end by ';' or, if it has a block, by '}'
- in a condition (e.g., for an IF) has different parts, use parenthesis
i) around non-atomic parts, and i) each time there may be a
for some readers (even if there is no
ambiguity for the interpreter/compiler due to
priorities of the used operators)
- your program and documentations must use correct English
error, ...) and no abbreviations except for
very common ones
- never remove code that may later be reused : instead, comment it
- you are encouraged to apply other conventions if they are compatible with
the other ones recommended in this teaching module
but apply them systematically (e.g., not half the time).