Created Whitespace FAQ (markdown)

This commit is contained in:
ReneSac 2014-03-28 23:00:20 -07:00
parent 8686c4c3a0
commit 8739680508
1 changed files with 65 additions and 0 deletions

65
Whitespace-FAQ.md Normal file
View File

@ -0,0 +1,65 @@
# WIP (really unfinished)
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 w/o some kind of editor highlighting. However, it has very visible effects on the code around it and, even when not needed, programmers use it to make the code more human readable. Whitespace in nimrod is only used as part of syntax in those cases.
# New Lines
Most statements have only one line. With semicolons languages, you pay a tax every line to be able to use multiline statements eventually. But as presented bellow, Nimrod 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 (forgot it). If none of those things occurs naturally on your line, you can always add a parenthesis around it all. 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:
```nimrod
someReallyLongProc(withMany, commands,
that may be broken,
in many lines)
var x = 2 +
2
var y =
[
1, 2, 3
]
```
# 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):
>```C
if (some condition)
if (another condition)
do_something(fancy);
else
this_sucks(badluck);
```
> Either the indentation is wrong, or the program is buggy, because an "else" always applies to the nearest "if", unless you use braces. This is an essential problem in C and C++. Of course, you could resort to always use braces, no matter what, but that's tiresome and bloats the source code, and it doesn't prevent you from accidentally obfuscating the code by still having the wrong indentation. (And that's just a very simple example. In practice, C code can be much more complex.)
### Tabs vs Spaces
This is a non-issue in Nimrod, as it only accepts spaces for indenting and will fail at compile time if it detects any problem (though you can trivially make a source code filter to convert your tabs to spaces, if you really prefer them). 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.
### 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 w/o 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
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.