ANN: Dao Language v.0.9.6-beta is release!

[Steven D'Aprano]

On Thu, 08 Dec 2005 08:23:52 +0000, Antoon Pardon wrote:

> Op 2005-12-07, Steven D'Aprano schreef <steve at REMOVETHIScyber.com.au>:
>> On Wed, 07 Dec 2005 15:26:59 +0000, Zeljko Vrba wrote:
>>
>>> Braces are very convenient to match block start and end. Open a C program
>>> in the VI editor, and press % in command mode on some brace.. It will take
>>> you to its matching brace. How do you do something like that with python code
>>> (or any code that is based purely on indentation..)
>>
>> (1) You don't need to, because you can *see* where the indentation
>> changes, so you don't need to rely on your editor counting for you.
> 
> But you can't alway easily discern by how much.

Admittedly, the blind and visually impaired might not. They will need a
screen reader that understands indentation.

Admittedly, a badly formatted arbitrary piece of text with arbitrary
indentation from line to line is difficult to judge.

But fortunately we're discussing code, not arbitrary text. Code will not
jump from one random level of indentation to another: there will often be
blocks of lines with the same indentation; when the indent level increases
it should always increase by one only; and when it decreases it will
usually decrease by one, sometimes two, more rarely three.

If your functions have more than, say, twelve levels of indentation, you
should be refactoring them.

If you are stuck reading other people's code, where they have hard-coded
indents as (say) two spaces, you may have trouble. But if they are using a
more standard four or eight spaces, it is easier to judge, and better
still if they use tabs, you can tell your editor to set the tabs to
whatever size works for you.

[snip]

> But sometimes you mess up and your code is no longer indented as it
> should. If you marked the end of the indentations, you can easily 
> correct this.

And sometimes you mess up and delete braces you shouldn't have. If you
had Or worse, you delete code you shouldn't have. Whoops!

Start/end markers (whether braces or keywords) plus indentation carry
redundant information. Redundancy means you can *sometimes* correct *some*
errors. But there are costs to redundancy: you have to carry the redundant
information around (in source code, in your head, in the complexity of the
parser) for the 99.99% of time that there is no error.

And what happens when the indentation and the markers disagree? Languages
like C decide arbitrarily that the markers are meaningful and indentation
is not, and it is a potent source of bugs and obfuscation.

Making a mistake in indentation level is precisely analogous to leaving
out markers in other languages. If your editor is smart enough, and the
code is not ambiguous, a smart editor will pick that up straight away. And
if not, the Python compiler will soon tell you, and you can then fix the
bug in your code.



-- 
Steven.