Workplace Practice

schrod@iti.informatik.th-darmstadt.de (Joachim Schrod) replied to Charles Fiterman

Further I find { } silly. Everyone in their right mind indents. Count indentation from the leftmost character of the previous line. Either eliminate tabs as valid within programs or give them some standard meaning like a tab takes you to the nearest 4's boundary.
That's fine as long as you write the program.

I often have to generate programs. In particular, I don't even generate the programs itself, but generate a pre-program that uses refinements to specify the bits and pieces that gets inserted in a common skeleton. (E.g., literate programming systems like noweb or nuweb may be (mis)used for that.) Preprocessors create the actual program that gets compiled.

In such circumstances it's a Bad Thing(tm) if white space in general (and particularly indentation) is used to specify control flow. It would get messed up much too often.
Unless the system you are using is aware of the problems and can work around them, but that does require a more specialised system, that knows about the specific languages (or at least the (syntactic) kinds of languages) it is being used with.

The markup language crowd learned it's lesson long ago: Please, no optical markup. Add explicit tags to your document. Why don't we stay with that?

mitchell@mdd.comm.mot.com (Bill Mitchell) responded to Joachim

I often work with source files which have been touched by multiple programmers. Besides introducing confusing style switches, everyone uses their own favorite editor. Some editors expand tabs to blanks, some to weird editor-specific combinations of tabs and blanks, and some put tabs in untouched. Where tabs are left in the file, individual programmers often pad the indent level with blanks to make it look right during their edit sessions (at least for the hardware tabstop settings their displays happen to have set during that editing session. If it has embedded tabs, it'll likely look very different if sent to a printer).

The resulting source file gets saved, compiled, tested, and checked in to the configuration management system. Often there's a rule forbidding running the source file through a formatting tool like indent(1) to regularize the indents because that messes up the number-of-lines-changed metrics produced when the files are checked in.

Inferring flow control from indent level just does not work in practice in a multi-programmer, multi-editor multi-display-format situation.

bevan@cs.man.ac.uk (Stephen J Bevan) replied to Bill Mitchell

Wouldn't the problem be solved if all the programmers on the project followed (and stuck to!) a style guide? I know it can grate to have to use a style which does not match your own, but IMHO the advantages outweigh the disadvantages on a multi-person project.

lutz@KaPRE.COM (Mark Lutz) also responded to Joachim Schrod

[indentation syntax makes it hard to generate programs]
Could you provide some more details? I've heard this argument before, but it's not clear to me that it would be any harder to generate N tabs than to generate block delimiters correctly. How hard is it to keep a global tab counter?

Even if you're just pasting blocks of code together randomly, you must have some notion of enclosing context, right? FWIW, I _have_ generated code for an indentation-based language (Python), with no problems at all. Perhaps you have some unique constraints (?)
Right, but a general system has to be tailored to take it into account, modifying each line in turn rather than just getting the {...} brackets right.

The markup language crowd learned it's lesson long ago: Please, no optical markup. Add explicit tags to your document. Why don't we stay with that?
But why must writing programs be like writing a document with a markup language? IMHO, we already have plenty of problems with maintainability as it is.

The point is that compilers should be able to use all the information communicated by the programmer (indentation, end-lines), rather than forcing extra, error-prone tokens.

Of course, YMMV; but I've seen many people become addicted to this syntax system, after using it.

plong@perf.com (Paul Long) responded to Mark Lutz

I assume he means that generating proper indentation is not as easy as generating a basically unindented program but with proper syntax. I can see his point, but I agree with you. I wrote an article for _The Journal of C Language Translation_ (vol. 3, no. 1, June '91) called "Emitting C Source" that presents an emitter that makes the generation of properly indented code as easy as unindented code.

schrod@iti.informatik.th-darmstadt.de (Joachim Schrod) replied to Paul Long

No, I think I wrote what I mean; it was in the deleted part.

It's convenient to use refinements when one generates programs. (There exist processors for them.) While generating one does not necessarily know the current lexical level. I don't think one should be forced to track it if not necessary, just because the language designer thought one *must* indent properly. OTOH, I'll virtually shoot any programmer working for me who does not indent properly.

Another example is the run-time generation of programs as strings that are evaluated later. It's more convenient to create a Lisp-like (i.e., fully parenthesized) structure -- and I think convenience is a very important point in language usage. It allows the programmer to focus on the problem at hand, not at the language quirks. (I'm not a friend of C and C++, can you tell? :-)

Or take as an example the generation of Makefiles. Here you have a language format where indentation and empty lines are important. (Even tabs are important.) Again one has to pay lots of attention in getting the quirks right, time that would be better spent working on solutions to the real problem...

Hope I expressed myself clearer this time,

Please don't tell me one should use other target languages & CM tools. Technical matters are only one (and most often minor) point in the selection of languages & tools for a project.