General programming rules

There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies; the other way is to make it so complicated that there are no obvious deficiencies. (C.A.R. Hoare)

A computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute. (The Structure and Interpretation of Computer Programs, H. Abelson, G. Sussman and J. Sussman, 1985.)

Programming IS NOT (just) about coding a program that seem to solve a given problem for the case you have thought about, it IS about creating a SCALABLE program that take into account as many situations as possible and delivers good/helpful error messages for all the different kinds of bad input that the user can enter. Scalable implies READABLE (clear, concise, consistent in following conventions) and MODULAR (as in "one function per task" and "no more than 30 lines per function" and "no more than 10 lines outside functions"; modularization also helps readability and re-usability). It should be remembered that the initial development of a program is usually a small fraction of the time and cost that is spent on it (later maintenances and extensions is where most of the time is spent, even when good programming languages are used and good programming methodologies are followed).

Interpreted languages such as Javascript encourage beginners to do (quick and) dirty programming, hence unreadable, unscalable, unmaintainable, bug-filled and hard-to-debug programs. It is therefore necessary to counter that by following as many programming conventions as possible. This document details some conventions/rules that you must follow (click here for a MINIMAL checklist of bad programming practices). You are strongly encouraged to complement this list by additional rules (consistent with those in the checklist) and follow them systematically (for example, if you define object classes, try to follow the JavaBeans conventions). The rules below will HELP YOU design and debug your programs since they are minimal ways to achieve better clarity, conciseness and modularity. Because of these underlying notions, you should have no difficulty to remember them, and you will have NO difficulty if (as you should) you apply them systematically whenever you write any line of code.

If you do not understand a rule, ask about it but do not ignore it!
NEVER start your programs from scratch (THE most basic rule of programming). In the context of this course, this entails the following: 1) test ALL the examples that you are given, 2) select the programs that you think you can re-use, 3) copy these programs in your directory to make sure they work in your directory, 4) correct these programs whenever they do not comply with the programming rules below, 5) test them again after this correction, 6) begin to modify these programs (progressivelly, incrementally) to achieve your goals.

For programs and documentations

For documentations only

For programs only