Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!seismo!mcvax!guido From: guido@mcvax.uucp (Guido van Rossum) Newsgroups: net.lang Subject: Re: More (ad nauseum) on removing punctuation in programming languages Message-ID: <7125@boring.mcvax.UUCP> Date: Thu, 30-Oct-86 20:17:46 EST Article-I.D.: boring.7125 Posted: Thu Oct 30 20:17:46 1986 Date-Received: Sat, 1-Nov-86 04:25:17 EST References: <21836@rochester.ARPA> <2642@hammer.TEK.COM> <694@looking.UUCP> Reply-To: guido@boring.uucp (Guido van Rossum) Organization: "Stamp Out BASIC" Committee, CWI, Amsterdam Lines: 113 Summary: superiority of indentation Apparently-To: rnews@mcvax [Context appended at end of article] The difference between misplaced braces bugs and misplaced indentation bugs is that misplaced (often: missing) braces are hard to find. See posted example (loop with one-line body + added debug statement). On the other hand, misplaced indentation is immediately spotted by the human reader, e.g. (using a language I am familiar with as example): PUT "" IN name GET.CHAR c WHILE 'a' <= c <= 'z': WRITE c PUT name^c IN name GET.CHAR c \ Bug! should be indented more Here, I would say, you notice the bug even while you are typing it, or if not, you'll catch it immediately when you peruse the program again after you find it gets stuck in an infinite loop. Thus, I find indentation sufficient. Sure, it's too late to add this, or any of the other proposed "improvements", to an existing language like C, or even to a new language that wants to be compatible, like C++. With computer languages, there is no "next year's model" which you can load with all the features you find missing in this year's model. Instead, there are longer-lasting "generations" where members of two or three generations live together, the young ones learning from the mistakes of old timers, some old timers picking up a few new ideas (Fortran seems to be in its third youth!), and the real future of the country being in the hand of youngsters that nobody takes serious yet. Sometimes a there is a real "wave movement": the third generation goes back to ideas of the first, that were utterly rejected by the second generation. An example is free formatting. When I was a kid, I learned that the free format of Algol was an improvement over Fortran's rigid "one statement per line" structure. (In Algol you could use a minimum number of punched cards for your program by formatting as in a massive block, but it also allowed the liberal insertion of spaces and indentation to display the program's intended meaning, as opposed to the interpretation understood by the compiler.) Very-high level languages such as Prolog and ABC again have one statement per line, and I've seen newly designed languages *with* goto statements! Also, in C, two statements on a line feel like a cardinal sin to me. Some more mundane points: the issues of mixing spaces and tabs are utterly system-dependent; when moving a file from one system to another with a different tab stop interpretation you should do a conversion, just like when converting from ASCII to CDC DISPLAY CODE. A practical problem may be that the conventions of the originating system are not known, and that users may set their own conventions (":se ts=4") that are not always understood by all tools in the programming environment. Luckily, auto-indent text editors are commonplace so typing in the indentation is no problem. If your indentation gets so deep there is no room for your statements on the line it is probably time to introduce another level of subroutines anyway. A form of indentation commonly found in Pascal programs is ridiculous: small indentation steps (one or two spaces) with one step for each syntactical production: case i in 1: begin if i=j then begin stuff; end else morestuff end end This makes it very hard to find matching begin/end pairs, especially if they span a page or two. Of course, this is neither an argument against Pascal nor against indentation: it only shows that religious application of any principle by small minds doesn't create great software. (Cf. the goto debate.) In my opinion, indentation should be displayed as at least three or four space. The 8 commonly used in C are excessive, but the only solution that is portable *and* easy to type. Syntax-directed editors can suggest an increase of indentation after certain statements like IF, FOR, WHILE. Decreasing the indentation again must be done manually, and I've struggled with at least three different systems without finding the ideal solution. VI is the worst: it requires a ^D to backspace over suggested indentation but ^H to reteat indentation you've just typed. Emacs allows you to use ^H at all times (I'm not talking of the various electric-C modes, which all too often impose a particular, often uncomfortable, formatting style, but about a normal auto-indent mode). A structured editor I've written myself interprets a [return] with the cursor at the begin of a line (after the indentation, that is) as a "dedent" operator. After a short learning period this feels very pleasant, especially since you can "dither" the return key: one return gives a new line, two returns in a row give a dedented line. Unfortunately, this does not extend to documents that may contain blank lines, or you'll need kludges like typing a space followed a return to keep a blank line. Ideas, anyone? -- Guido van Rossum, CWI, Amsterdam [Some context:] In article <694@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes: >In article <2642@hammer.TEK.COM> andrew@hammer.UUCP writes: >>If you think it's easy to misplace a curly brace, you ain't seen >>nothing until you go looking for the subtle program misbehavior caused >>by incorrect indentation! > >True, and very important. Indentation is guaranteed to balance out by the >end of the program. There's no such thing as an error, as far as the compiler >can detect (except in a few cases where extra keywords like else appear). > >If you're using a regular text editor, using indentation can be very dangerous. >As Mr. Klossner suggests, the correct suggestion is to use both closers and >indentation, redundantly. Since the indentation supplies the visual cues, >the closers should be unobtrusive, but present.