Re: Automated indentation

Thomas Kofler (
Wed, 11 May 1994 19:30:50 GMT

Obviously, the missing syntax for terminating code blocks
in python is a topic of general interest. The following tries
to summarize the most interesting statements (IMHO).

Thomas Kofler |Email:
Union Bank of Switzerland |Tel: +41-1-236 4567
Bahnhofstr. 45 |Fax: +41-1-236 4671
CH-8021 Zurich, Switzerland |

[ wrote: ]
> But: I dislike the fact that blocks of statements are not enclosed by
> balanced parentheses (or something like that)

[ 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 <> 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...).

[ (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.

[ 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 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.