----------------------------------------------------------
Thomas Kofler |Email: kofler@ubilab.ubs.ch
Union Bank of Switzerland |Tel: +41-1-236 4567
Bahnhofstr. 45 |Fax: +41-1-236 4671
CH-8021 Zurich, Switzerland |
----------------------------------------------------------
[ Thomas.Kofler@ubilab.ubs.ch wrote: ]
> But: I dislike the fact that blocks of statements are not enclosed by
> balanced parentheses (or something like that)
[ Guido.van.Rossum@cwi.nl wrote: ]
> - Since there are no begin/end brackets there cannot be a disagreement
> between grouping perceived by the parser and the human reader. I
> remember long ago seeing a C fragment like this:
> if (x <= y)
> x++;
> y--;
> z++;
As much as one can forget to group statements correctly by
block begin/block end, one can indent code wrong.
> - Since there are no begin/end brackets there can be no conflicting
> coding styles.
If the syntax of a language allows automatic reformating no matter
how weird the code looks, a user can reformat the program according
to her taste (or to that of her manager, etc.)
> - Many coding styles place begin/end brackets on a line by themself.
> This makes programs considerably longer and wastes valuable screen
> space, making it harder to get a good overview over a program.
Many coding styles possible in C/C++ are quite compact, eg:
if ( bla1 ) { Error(cBla1); return -1; }
if ( bla2 ) {
Error(cBla2); return -1;
}
My experience shows that people do not always format code with one
one-size-fits-all rule.
[ George Reynolds <george.vicorp.com> wrote: ]
> As a program is evolving (as opposed to simply reading the code) one
> is often cutting, pasting and otherwise modifying code quite
> frequently.
This is perfectly true. For instance, selecting in a terminal emulator
(like xterm) some piece of code (no tabs, only space in the buffer
to paste from), and then pasting into a file loaded in vi...
> Also, mistakes do happen. For example when using python-mode in emacs,
> I hit tab on a line by mistake and that line gets indented 5 levels.
> Where was it originally? Impossible to know unless I stop and grok the
> meaining of the function... again.
Strong argument. Consider inadvertently removing
one tab (the time invested in finding the "bug" could be spent
on more interesting things...).
[ mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz) wrote: ]
> Certainly - even if one had to reindent some ill-formatted code, it
> would then at least be possible to do, without having to understand
> it in detail.
The same strong argument in a slightly different context.
[ Guido.van.Rossum@cwi.nl wrote: ]
> I still don't like it, but I suppose for the benefit of people who
> simply can't live with indentation, maybe we can invent an optional
> keyword to be introduced at the end of an indented block, like
>
> if foo and bar:
> important_stuff()
> more_important_stuff()
> else:
> less_important_stuff()
> end if
>
> where the 'end if' line would be optional and would have to be
> indented properly and could be used by a re-indent routine.
This would be much better than the current state.
[ Tim Peters tim@ksr.com wrote: ]
[ ... ]
> a scheme that can't deal
> with a Python program presented as a single long newline-free string
> doesn't achieve all the things block-closers _should_ achieve.
I think that this is *the* criterion.