Re: The semicolon habit (was: Q: Definition of a scripting lang.)

Charles Fiterman <cef@geodesic.com> writes:
> 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.


schrod@iti.informatik.th-darmstadt.de (Joachim Schrod) said:
>That's fine as long as you write the program.
>[...]
>In such circumstances it's a Bad Thing(tm) if white space in general
>(and particularily indentation) is used to specify control flow. It
>would get messed up much too often.
>[...]


I'm not a regular reader of this group, but I stumbled across the
above and thought I'd add a thought. 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 wierd 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.


--
mitchell@mdd.comm.mot.com (Bill Mitchell)
--

Return to the comp.compilers page.
Search the comp.compilers archives again.