> <\body> There a few rules about coding style that we try to follow ourselves in the 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. 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: <\mmx-code> hamming_distance (i: Int, j: Int): Int == ...; Of course, standard mathematical functions such as , , , carry their traditional names. We also recall the following general conventions from the section about : <\itemize> Use lowercase names for variables and functions. For names of types and categories, capitalize the first letter of each word categories ( or ). Capitalize all letters in macro names. Use the suffix for names of predicates. The following indentation rules are implemented both in and in the mode for . In both cases, you may use the key for indenting the current line. Blocks of code are usually indented by two spaces. For instance: <\mmx-code> 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: <\mmx-code> 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: <\mmx-code> mmout \\ "first line" \\ lf \ \ \ \ \ \ \\ "second line" \\ lf; Functions or vectors with many arguments are indented as follows: <\mmx-code> 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 indentation rules: <\mmx-code> if a = 1 then return 2*x + 3*y + 4*z; \ \ \ \ \ \ \ \ \ else return 3*x + 4*y + 2*z; There are a few less strict rules concerning whitespace management: <\itemize> Function application takes one space before the bracket and after every <\mmx-code> r: Int == foo_bar (x, y, z); and similarly for data access using : <\mmx-code> val: Val == my_table [key]; When the name of the function or data structure is particularly short, we may omit the space before or : <\mmx-code> 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 <\mmx-code> 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 <\mmx-code> 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: <\mmx-code> 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: <\mmx-code> x1: R == a + 2*b + 3*c; x2: R == x[1] * x[2]^2 * x[3]^5 + 123 * x[1]^7 * x[2]^11; . If you don't have this file, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.>