There a few rules about coding style that we try to follow ourselves in the Mathemagix libraries written in our own language. Although these rules are not mandatory, the readability of your code should be easier for others if you follow them.

1.Naming conventions

In general, we try to avoid abbreviations when chosing names for global variables, functions, classes and categories, and choose short (often one letter) names for local variables. For instance:

hamming_distance (i: Int, j: Int): Int == …;

Of course, standard mathematical functions such as exp, log, cos, etc. carry their traditional names. We also recall the following general conventions from the section about regular identifiers:

• Use lowercase names for variables and functions.

• For names of types and categories, capitalize the first letter of each word categories (e.g. Integer or Ordered_Group).

• Capitalize all letters in macro names.

• Use the ? suffix for names of predicates.

2.Indentation

The following indentation rules are implemented both in TeXmacs and in the Emacs mode for Mathemagix. In both cases, you may use the ⇥ key for indenting the current line.

Blocks of code are usually indented by two spaces. For instance:

if x < y then {
  z: T == x;
  x := y;
  y := z;
}

Multiple line bodies of keywords are enclosed between braces { and }, whereas one line bodies are simply indented whenever we put them on separate lines:

if weather = "cold" then
  mmout << "take a coat!" << lf;
else if weather = "hot" then
  mmout << "a T-shirt will suffice" << lf;
else
  mmout << "syntax error in weather; please call Meteo France" << lf;

Input/output operators are indented as follows:

mmout << "first line" << lf
      << "second line" << lf;

Functions or vectors with many arguments are indented as follows:

mmout << beginners_function (a, b, c, d, e, f, g, h,
                             i, j, k, l, m, n, o, p,
                             q, r, s, t, u, v, w, x) << lf;
v: Vector Int == [ 10000, 10001, 10010, 10011, 10100, 10101, 10110, 10111,
                   11000, 11001, 11010, 11011, 11100, 11101, 11110, 11111 ];

Sometimes, the readability can be enhanced by using ad hoc indentation rules:

if a = 1 then return 2*x + 3*y + 4*z;
         else return 3*x + 4*y + 2*z;

3.Spacing rules

There are a few less strict rules concerning whitespace management:

• Function application takes one space before the bracket ( and after every ,

  r: Int == foo_bar (x, y, z);

  and similarly for data access using postfix []:

  val: Val == my_table [key];

  When the name of the function or data structure is particularly short, we may omit the space before ( or [:

  mmout << f(x) + g(y) + h(z) << lf; mmout << v[1] * v[2] * v[3] << lf;

• Long mathematical expressions which do not fit on one line, such as

  return [ (-b - sqrt (square b - 4*a*c)) / (2*a), (-b + sqrt (square b - 4*a*c)) / (2*a) ];

  are usually split over several lines, by introducing some auxiliary variables

  disc: C == square b - 4*a*c; return [ (-b - sqrt disc) / (2*a), (-b + sqrt disc) / (2*a) ];

• When defining a succession of variables, align the definitions on the : and == (or :=) symbols, if this does not leave to much whitespace:

  Ints ==> Vector Int; x1: Int == a + 2*b + 3*c; x2: Int == p + 2*q + 3*r; v : Ints == [ x1, x2 ];

• Use whitespace around mathematical infix operations whenever this enhances readability:

  x1: R == a + 2*b + 3*c; x2: R == x[1] * x[2]^2 * x[3]^5 + 123 * x[1]^7 * x[2]^11;