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 programming, program presentation,
indenting and naming.
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.

Environment  (-1/20 each time you are caught not following these rules)

1. 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.
2. Lines must be less that 79 characters long and short enough for
   not causing line wrappings (or characters to be invisible) on your screen.
3. The open windows must not overlap. Reminder: to be efficient, you should
   NOT have to regularly swap or scrop windows.
4. The Javascript console must be open and have all its options enabled (except for
   "Net" which is optional). Reminder: you work environment must be ready when
   the class teaching begins.
5. The HTML tag for the title for your result window must contain your name.
6. You must use a computer mouse, NOT the touchpad of your computer, unless you
   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
   using the touchpad.

Content

1. 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 in CM/TD).
   When sent as an attachment in an e-mail, HTML+Javascript programs must be
   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 displays well
   and executes well from a navigator called from your email client.
   Use "devoir" in the "Subject:" part of your e-mail.
   (0/20 if the program cannot be directly executed).
2. 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.
3. The recommended information must be provided and the
   error-preventing conventions must be followed
   (-1/20 per missing information or not respected convention), e.g.,
   - all the required information in the header should be provided
   - Javascript programs must have "use strict" at their beginning
   - 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 log
   - 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.
4. 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)

1. The recommended naming conventions (for files/functions/variables/constants/...)
     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 English and
     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 case)
   - 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"
2. 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 and
     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 (i.e.,
     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 line wrappings)
3. 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 potential ambiguity
     for some readers (even if there is no ambiguity for the interpreter/compiler due to
     the different priorities of the used operators)
   - your program and documentations must use correct English (no lexical/grammar
     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).