<- ^ ->

Coding conventions

2   Coding conventions

Comment much. I know, there are not too much comments in the code at the very moment, but please forgive me, I'm working on it.

Leave code clean and warning free. This is especially true for OCaml warnings about pattern matching. The usual way of adding new things, is to add them to datatypes, and fix match'es, until you'll get warning-free compilation :-)

Code should fit 80 column screen.

2.1   For OCaml code

Basic indentation level is 2. Set expandtab option in your editor, so we have no \t in source files.

It is often to list all cases in patter matching, like:

    match t with
        NamedType r -> NamedType {r with nt_module = m}
      | Int | Void | Bool | Float | String | TyVar _ | AbstractType
      | Tuple _ | Func _ | Struct _ | OptStruct _ | Union _ -> t 
while one could have used:

    match t with
        NamedType r -> NamedType {r with nt_module = m}
      | _ -> t
which would be shorter, and probably more readable. However, after we have added new type, we should check each place, where we use pattern matching on type to see if it needs special case. OCaml will warn you if you add new type in the first case (it is unmatched), in the second -- it won't.

2.2   For C code

indent -kr -i8, parse: K&R, tabstops are 8 spaces long. Don't use expandtab, we want \t's here.

Example (very stupid one):

        int f(int a, int b)
        {
                while (a != 0) {
                        if (a == b) {
                                a = b;
                        } else {
                                b = c;
                        }
                        switch (c) {
                        case C1:
                                c = 1;
                                break;
                        case C2:
                                c = 2;
                                break;
                        }
                }
        }
Functions should be small (1-2 screens).

Why -kr? Because (1) K&R are right, (2) K&R are right, and (3) K&R are right. Why -i8? After 15th hour of hacking, you'll surly find out why... If you get far too far to the right with such a huge indent, it means your functions are far too big (borrowed from CodingStyle file that comes with linux kernel).

<- ^ ->

Coding conventions