On Tuesday, 15 January 2013 at 13:43:12 UTC, Chris wrote:
> On Tuesday, 15 January 2013 at 12:36:42 UTC, bearophile wrote:
>> Chris:
>>
>>> Nested for loops with if-statements can be hard on the eye in Python, because you have to go back an double check on which level you actually are
>>
>> If you use the standard 4 spaces indentations and you don't have ten indentation levels this problem is not common. Some persons also avoid your problem with an editor that shows thin vertical lines every 4 spaces (but only where the lines are actually reaching that length).
>>
>>
>
> It happens very quickly if you have a class, a def, a nested for loop with one or two if statements
>
> class:
>     def:
>         for:
>             if:
>
> You could call it "south west" code.

I'm not sure what is your point, even with 5 level of indentations and the standard 4 space indentations, on a normal 80 colum window you still have 3/4 of the window for the code..

renoX

On Wednesday, 16 January 2013 at 15:55:09 UTC, renoX wrote:
> On Tuesday, 15 January 2013 at 13:43:12 UTC, Chris wrote:
>> On Tuesday, 15 January 2013 at 12:36:42 UTC, bearophile wrote:
>>> Chris:
>>>
>>>> Nested for loops with if-statements can be hard on the eye in Python, because you have to go back an double check on which level you actually are
>>>
>>> If you use the standard 4 spaces indentations and you don't have ten indentation levels this problem is not common. Some persons also avoid your problem with an editor that shows thin vertical lines every 4 spaces (but only where the lines are actually reaching that length).
>>>
>>>
>>
>> It happens very quickly if you have a class, a def, a nested for loop with one or two if statements
>>
>> class:
>>    def:
>>        for:
>>            if:
>>
>> You could call it "south west" code.
>
> I'm not sure what is your point, even with 5 level of indentations and the standard 4 space indentations, on a normal 80 colum window you still have 3/4 of the window for the code..
>
> renoX

My point is that Python code is not necessarily more readable only because it enforces indentation via syntax. If the code between the different blocks (for, if, else etc) is long enough, you easily lose track of where exactly you are when scrolling down, just like in any other language (Yes, you need tools that help you!). And one of the biggest drawbacks is that it is a nuisance to cut and paste or comment out in Python because you have to format your code _before_ you even know whether it works as desired. If it doesn't, all the extra formatting work was in vain. So much for "saving time". I do believe that abstract ideals should not be given precedence over (coding) reality. If Python is the ideal, why and how do other languages manage to survive? How can people read code written in other languages at all?

As has been said many times before, it should not be the language's job to enforce indentation. This should be handled by customizable code editors. Any programmer in his/her right mind will use indentation. So why enforce it through syntax rules?

Am 21.01.2013, 15:42 Uhr, schrieb Chris <wendlec@tcd.ie>:
> As has been said many times before, it should not be the language's job to enforce indentation. This should be handled by customizable code editors. Any programmer in his/her right mind will use indentation. So why enforce it through syntax rules?

The discussion about using indentation as block delemeter is a holly
war about personal preferences IMHO.

There is a strong argument against enforced indentation: Automatic
code generation is hard or even impossible in languages like Python.
I don't think it makes any sense in languages with generics.

Much more important is an  orthogonal and consistent syntax...

Peter

On Tuesday, 15 January 2013 at 12:09:21 UTC, bearophile wrote:
> 1100110:
>
>> Thats so funny I forgot to laugh.
>
> One common indentation-related bug is caused by relying on the indentation to understand code, while the curly brace language compiler ignores what you were seeing and only sees the braces. I have seen many cases of delayed code understanding caused by that. Making the syntax more DRY (this means stating the logical indentation using only one communication channel) helps avoid those mistakes (and reduces the visual noise, further helping code readability).
>

The sane option are either to acknowledge that code is in a text file and choose syntax construct that make it readable (python) or decorrelate the presentation of the code from its actual form in the file and use a formatted.

Other options are choosing on purpose to inflict an extra workload to yourself, and risking confusion on badly formatted code.

On Tuesday, 22 January 2013 at 03:00:59 UTC, deadalnix wrote:
> The sane option are either to acknowledge that code is in a text file and choose syntax construct that make it readable (python) or decorrelate the presentation of the code from its actual form in the file and use a formatted.

Out of the two options, I would say that the correctness of the source should not be dependent on how it is formatted. One advantage of this, is that you can compact the source by removing all unnecessary white space and line returns. Another reason is that source code can be automatically generated without the costly complication of having to correctly format it.

Compacted source code works well for transmission over a network and for storage in a database. Sure, speeds are high and storage is cheap, but if you consider something like javascript, there's an overall huge amount of continual resource waste when needlessly formatted code is transmitted, interpreted, and stored. This is why JS code is usually compacted when it goes into a release state.

--rt