Cleanup, get ready to other page

This commit is contained in:
flaviut 2014-10-11 15:51:51 -07:00
parent 0a8e99f0be
commit e07f1e1a6a
1 changed files with 19 additions and 18 deletions

View File

@ -2,9 +2,16 @@
-----------------
Virtually all programming languages use whitespace as part of their syntax. Many only as a token separator. Whitespace by itself is invisible, and you can't differentiate a tab from a space without editor highlighting or differentiation. Despite this, whitespace has very visible effects on the code around it and, even when not strictly required by a language's syntax, programmers still use it to make code readable. Whitespace in nimrod is only used as part of syntax in those cases.
The goal of this document is to improve the readablity code in the Nim standard library and compiler, as well as to be a source for the "Official" coding conventions.
# New Lines
# General Rules
* Use the implicit "result" variable and try to avoid "return".
* Do not use templates/macros when an inline proc suffices.
* Do not use "nil" for strings and sequences. The procs of the standard library which misuse "nil" as an error value will be deprecated.
# 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.
@ -36,7 +43,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
# Indentation
## Indentation
In 'curly braces languages', indentation works like comments. You will put it to make the code understandable, but its meaning is not enforced by the compiler/interpreter and thus can get out of sync with the real meaning, defined by the braces, or lack of it. This can lead to dangerously ambiguous code (for humans to understand, of course). For example (from ["Python: Myths about Indentation"](http://www.secnetix.de/~olli/Python/block_indentation.hawk)):
@ -53,23 +60,17 @@ else
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.
## Deep nesting
### Sharing code
Many editors have an option to visibly show indentation markers, helping to visualize more easily the different levels, but code should not be indented too deeply since it is frequently a sign that parts should be refactored into smaller functions.
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 indentation sucks.
`#{` and `#}` are also an option, with a script to reindent it.
### Copy pasting
Most editors support , by selecting the lines and , (for example, `tab` for indent and `shift` + `tab` to dedent).
### Deep nesting
Many editors have an option to visibly show indentation markers, helping to visualize more easily the different levels. Or refactor the code in functions.
# Strong spaces
## Strong spaces
A experimental feature, currently only available through a source code filter, is strong spaces. The relative spacing between operators and operands overrides their standard precedence, like adding parenthesis would.
Only 0, 1, 2, 4 or 8 spaces are allowed and the compiler enforces that infix operators have the same amount of spaces before and after them. This rules does not apply when a newline follows after the operator, then only the preceding spaces are considered.
Only 0, 1, 2, 4 or 8 spaces are allowed and the compiler enforces that infix operators have the same amount of spaces before and after them. This rules does not apply when a newline follows after the operator, then only the preceding spaces are considered.
# 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.