3 The syntax of Nit follows the Pascal tradition and is
4 inspired by various script languages (especially Ruby). Its main objective is
7 Indentation is not meaningful in Nit; blocks usually starts with a
8 specific keyword and finish with `end`. Newlines are only meaningful at
9 the end of declarations, at the end of statements, and after some
10 specific keywords. The philosophy is that the newline is ignored if
11 something (a statement, a declaration, or whatever) obviously needs more
12 input; while the newline terminates lines that seems completed. See the
13 complete Nit grammar for more details.
16 # a first complete statement that outputs "2"
18 # the second statement is not yet finished
20 # the end of the second statement, outputs "4"
24 Nit aims to achieve some uniformity in its usage of the common
25 punctuation: equal (`=`) is for assignment, double equal (`==`) is for
26 equality test, column (`:`) is for type declaration, dot (`.`) is for
27 polymorphism, comma (`,`) separates elements, and quad (`::`) is for
32 Identifiers of modules, variables, methods, attributes and
33 labels must begin with a lowercase letter and can be followed by
34 letters, digits, or underscores. However, the usage of uppercase letters
35 (and camelcase) is discouraged and the usage of underscore to separate
36 words in identifiers is preferred: `some_identifier`.
38 Identifiers of classes and types must begin with an uppercase letter and
39 can be followed by letters, digits, or underscores. However
40 the usage of camelcase is preferred for class identifiers while formal types should be written in all uppercase: `SomeClass` and `SOME_VIRTUAL_TYPE`.
44 While Nit does not enforce any kind of source code formatting, the
45 following is encouraged:
47 - indentation uses the tabulation character and is displayed
50 - lines are less than 80 characters long;
52 - binary operators have spaces around them: `4 + 5`, `x = 5`;
54 - columns (`:`) and commas (`,`) have a space after them but not
55 before: `var x: X`, `[1, 2, 3]`;
57 - parenthesis and brackets do not need spaces around them;
59 - superfluous parenthesis should be avoided;
61 - the `do` of methods and the single `do` is on its own line and not
64 - the other `do` are not on a newline.
66 ## Comments and Documentation
68 As in many script languages, comments begin with a sharp (`#`)
69 and run up to the end of the line. Currently, there is no
72 A comment block right before any definition of module, class, or
73 property, is considered as its documentation and will be displayed as
74 such by the autodoc. At this point, documentation is displayed verbatim
75 (no special formatting or meta-information).