Updated name from Nimrod to Nim.
This commit is contained in:
parent
bd9e9abc7b
commit
f7ff2fc454
|
@ -5,15 +5,15 @@
|
|||
# Whitespace
|
||||
## New Lines
|
||||
|
||||
Most statements have only one line, and are followed by a line break. With languages whose lines are delimited by semicolons, the programmer pays a tax every line, just so that multiline statements can be used. But as presented below, Nimrod lets you use multiline statements most of the time w/o requiring this semicolon tax.
|
||||
Most statements have only one line, and are followed by a line break. With languages whose lines are delimited by semicolons, the programmer pays a tax every line, just so that multiline statements can be used. But as presented below, Nim lets you use multiline statements most of the time w/o requiring this semicolon tax.
|
||||
|
||||
Really long lines that must be broken are bad style, but often unavoidable. In those cases, Nimrod provides many implicit continuation . The rule of thumb is that after a `,`, unary or binary operators and `(` `[` `{` you can safely put a line break and continue the statement in the following line. If none of those things occurs naturally, you can always add a parenthesis. Two characters in those exceedingly rare situations, instead of one character every line.
|
||||
Really long lines that must be broken are bad style, but often unavoidable. In those cases, Nim provides many implicit continuation options. The rule of thumb is that after a `,`, unary or binary operators and `(` `[` `{` you can safely put a line break and continue the statement in the following line. If none of those things occurs naturally, you can always add a parenthesis. Two characters in those exceedingly rare situations, instead of one character every line.
|
||||
|
||||
After a continuation, the code can be positioned quite freely. The only rule is that the continuing line must be indented at least one level above the first line.
|
||||
|
||||
For example, all the following nimrod code is valid:
|
||||
For example, all the following Nim code is valid:
|
||||
|
||||
```nimrod
|
||||
```nim
|
||||
|
||||
someReallyLongProc(withMany, commands,
|
||||
that, may, be, broken,
|
||||
|
@ -33,7 +33,7 @@ const DeBruijnNumbersTable: array[32, int8] =
|
|||
|
||||
```
|
||||
|
||||
Nimrod also has semicolons. They are redundant as simple statement terminators, but useful if you want to fit multiple statements in one line. Statement lists can also be used in some places where you would need to define a block using indentation
|
||||
Nim also has semicolons. They are redundant as simple statement terminators, but useful if you want to fit multiple statements in one line. Statement lists can also be used in some places where you would need to define a block using indentation
|
||||
|
||||
## Indentation
|
||||
|
||||
|
@ -50,7 +50,7 @@ else
|
|||
|
||||
### Tabs vs Spaces
|
||||
|
||||
This is a non-issue in Nimrod, as only spaces are accepted as an indentation character --- a syntax error will be thrown if the compiler detects tabs being used for indentation (though this can be worked around by using a [syntax filter](http://nimrod-lang.org/filters.html)). However, languages that allow both of them to be mixed are dangerous. Some languages, like python 2 by default (fixed on python 3), tries to convert a tab to a certain number of spaces, and thus an indentation error introduced by mixing tabs and spaces will only be detected as a run-time failure. Other languages, that ignores any type of indentation, will generate code that behaves differently than it looks at first sight when using an editor with different tab-stops configuration. This can hide/introduce bugs, like in the previous C/C++ example.
|
||||
This is a non-issue in Nim, as only spaces are accepted as an indentation character --- a syntax error will be thrown if the compiler detects tabs being used for indentation (though this can be worked around by using a [syntax filter](http://nim-lang.org/filters.html)). However, languages that allow both of them to be mixed are dangerous. Some languages, like python 2 by default (fixed on python 3), tries to convert a tab to a certain number of spaces, and thus an indentation error introduced by mixing tabs and spaces will only be detected as a run-time failure. Other languages, that ignores any type of indentation, will generate code that behaves differently than it looks at first sight when using an editor with different tab-stops configuration. This can hide/introduce bugs, like in the previous C/C++ example.
|
||||
|
||||
## Deep nesting
|
||||
|
||||
|
@ -65,4 +65,3 @@ Only 0, 1, 2, 4 or 8 spaces are allowed and the compiler enforces that infix ope
|
|||
# Sharing code
|
||||
|
||||
Use dedicated source code paste sites and tags, that usually also gives you syntax highlighting and maybe even versioning and forking support. Having to read code on the internet without syntax highlighting and stripped indentation sucks. https://gist.github.com/ is ideal for this.
|
||||
|
Loading…
Reference in New Issue