Assignment 4
ML Coding Guidelines

ML coding guidelines

1. 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.
   
   
2. 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.
   
   
3. 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.
   
   
4. 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.
   
   
5. 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.