University of Toronto - Winter
2007
Department of Computer Science
CSC 324
:
Principles of Programming Languages
Assignment 4
ML Coding Guidelines
ML coding guidelines
- Using pattern matching
The use of pattern matching whenever possible is considered
good style. For example, rather than defining
fun sum L = if null L then 0 else hd L + sum (tl L);
it is better to define
fun sum [] = 0
|   sum (h::t) = h + sum t;
Make sure that your functions exhaust all possible
patterns. If you get a warning "Warning: match nonexhaustive",
this is a bad sign: marks will be deducted.
- Comments
Each function you write, including all helper functions,
should have a concise and clear description of the function,
the argument, preconditions, postconditions, and return
value, and last but not least the type of the
function. Type information shound not be included in
the function preconditions. The type of each function should be
provided in a separate statement in the function's head comment.
Any preconditions not related to types, such as specific assumptions
you are making about the form of a function's inputs, should
be listed in the preconditions.
- Indentation
We should be able to tell the structure of your function
simply by looking at it. I.e. it should be very clear what is
a function call, what is the argument to a function, what is
the condition in the if statement, and what is the
consequent.
- Efficiency
You do not have to go out of your way to optimize your
algorithms. However, your code should be reasonable. You
should not be evaluating the same thing multiple times, for
example. You should not traverse lists unnecessarily.
You should not create superfluous variables or bind variables
unnecessarily.
- Style
Your code should be nice. Of course, it is difficult to say what
"nice code" is. Use your judgement.
if condition then do A
else do A
is not a "nice" piece of code.
if x >= 0 do A
if x < 0 do B
else do C
is not a "nice" piece of code either.
It should be clear to the reader that your code does not work
by some magic simply because you tried 10000 different
versions and one of them finally worked. It should be clear
that you know what you are doing.
Your should pick informative names for your helper functions,
as well as for all arguments.
For multiline comments the following is considered good
style:
(* comments
 * comments
 * comments
 * comments
 * comments
 * comments *)
General coding guidelines
- Correctness
The program should conform to the specifications for which it
was written. It should include correct handling of special
cases, except that you may assume that input will be provided
in the specified format (i.e. you can use
programming-by-contract)
- Design and Efficiency
The program should be constructed from small, coherent,
independent and loosely coupled functions. Each function
should access only its own parameters. The control constructs
and data structures used should be those appropriate to the
problem at hand. The program should not perform unnecessary
steps, use extraneous variables, nor implement the algorithm
in a contorted or inefficient way.
- Style and Documentation
The program should conform to generally accepted principles of
style, such as a consistent pattern of indentation, use of
meaningful identifiers, generous use of space, etc. Internal
documentation should include program and function headers, and
in-line comments to clarify the code.
Back to the main page