Minimal checklist of bad programming practices

See the 'programming rules' document for some details and rationales behind the listed errors.

1. Working with a bad "development environment", e.g.:
   1) not having a text editor on one side of your screen (left side when at the ESIROI)
       and all you other windows (results/interface/documentation/...) on the other side and not overlapping;
       reminder: you should NOT have to regularly swap windows or use the scrollers
   2) working with Javascript without having the javascript console opened
   
2. Not using common naming conventions (for file/variable/procedure names), e.g.:
   1) not following the Intercap style
   2) not beginning the name of a global variable by an uppercase
   3) not beginning a file name or the name of a local variable by a lowercase
   4) using an uncommon abbreviation within a name (watch out for typos too)
   5) not using uppercases for the name of a constant
   6) not beginning the name of a boolean variable/function by "is" or "has"
   7) not using an object-oriented style when it is easy to do so (it most often is)
   8) not following the HTML form element naming conventions.
3. Having a poorly documented code:
   1) Not putting at least the following information in a file header:
   - student name and number for the creator
   - creation date
   - description of purpose
   - names and types of the parameters
   - names of the input and output files
   - list of the kinds of data validation implemented or to implement
   - name of the files used to test it
   2) not putting a comment before a subroutine/function when this helps understand it
   3) not using comments to explicit the type of a variable when the type is not obvious.
4. Having a poorly readable source code (including in the comments):
   1) Having a poorly structured code:
   - duplicating code (of more than 2 lines) at different places
   - having a procedure/function/program with more than 20 statements in a row
   2) using incorrect indentation
   3) using tabulation characters (unless the program is guaranteed to be always edited with the same tools and on the same platform)
   4) having a line more than 70 characters long (unless the program is guaranteed to be always edited and printed with the same tools and on the same platform)
   5) not aligning block delimiters (vertically or horizontally)
   6) within an If-Then-Else statement, putting the (much bigger) block first
   7) not using 1 space before and after a single '=' used for an equality test
   8) using 1 space before an '=' used for an assignment
   9) using a word in uppercase (except for naming a constant)
   
5. Not using easy ways to prevent errors:
   1) not using an option forcing the declaration of variables when the language you use has this option (e.g., "use strict" in Perl, "Option Explicit" in VBscript and "ini_set('error_reporting',E_ALL);" in PHP)
   2) not initializing a variable before it is used
   3) not validating a user's input, client-side and server-side
   4) using a transfer/redirect instruction from a program to another
   5) not solving syntax error messages or warnings
   6) not solving infinite loops
   7) not closing a file before exiting
   
6. Developing bad interfaces:
   1) still having a "trace outside the console log" in the final version of your program
   2) using abbreviations within your interface (watch out for typos too)
   3) letting the user choose record IDs when adding records
   4) letting the user know internal IDs of records
   5) forcing the user to enter non-mandatory values of a record
   6) forcing the user to re-enter values in case of input error or unfound records
   7) forcing the user to navigate or enter values when it is possible to avoid it
   8) using the POST parameter encoding method for calling information retrieval/display programs
   9) not having a static HTML file named "index.html" as entry point ("Index.html" or "index.htm" is an error,at least in this course)