🚀 go-pugleaf

In article <4255vr$12@mujibur.inmind.com> mfinney@inmind.com writes:

>Given those considerations, requiring that a particular indentation
>style be followed for all users of a langauge is not that obnoxious.
>Especially when the benefit of doing so is to make code syntax
>simpler (to a human) and to reduce the number of bugs.  Not to
>mention reducing typing!  Finding problems such as...
>
>   if (aTest)
>         aStatement1;
>      else
>         aStatement2;
>         aStatement3;
>
  <snip>
>
>And, wait there's more! <GG>, not only did I eliminate
>braces and semicolons, but I was also able to eliminate
>other parts of the syntax (such as "else if" in a else-if
>chain).  My tests indicated that those rules resulted in
>about a 30% non-white space reduction in a typical
>program.  Perhaps less today, with longer variable and
>function names common.

And, of course, you will have to mandate the width of tabs 
and/or forbid the use of tabs.  Otherwise, what happens when 
you edited with tabs set to 8 and the compiler expects 4?

  --->  tab
  ....  spaces

Edited:

....if(aTest)
........aStatement1;
....else
........aStatement2;
------->aStatement3;


Compiled:

....if(aTest)
........aStatement1;
....else
........aStatement2;
--->aStatement3;		//  whoops.


I would much rather rely on layout-independant braces to define 
my block scope.

What happens when someone fouls up with global search and replace 
or strange editors which changes the spacing/indentation?  I have 
had both done to me and it would have been a nightmare having to 
go laboriously through code re-creating the block structure.

--
============================================================================
 Ian Cargill  CEng MIEE |  Find out about the Association of C and C++ Users
 Soliton Software Ltd.  |  info@accu.org  OR http://bach.cis.temple.edu/accu