• Era Scarecrow <rtcvb32 yahoo.com> Jan 23 2012
• bcs <bcs example.com> Jan 23 2012

Era Scarecrow <rtcvb32 yahoo.com> writes:

 From: "Nick Sabalausky" <a a.a>
 '''
 White space may consist of:
 - A comment between any two tokens.
 - A single space between tokens that, if adjoined would


 All other white space (including \n \r \t \v, etc.) is


 lexical error.
 '''

 With these additions, all valid D code will be so hard


 will ever attempt to read it without first running a


 and once that is standard practice, everyone will see


 preferred style.


 Hah! I like it :)


 It does have a certain amount of sense it makes... but if that were really an
issue, then having your won formatter strip the unneeded spaces and then
re-introducing them back seems trivial, in which case a indentation tool would
be more likely to be used (GNU indent anyone?).

 It does however become an issue regarding debugging, if sources are compiled
against said compacted sources in that way. Everything would be on line 1, and
other such messes. Course if your compiling the sources yourself and run it
through your formatter your fine. But if someone else has their own format and
download the source and reformat it to their format, line 117 may not point to
anything, or point to the wrong object, or worse yet, if an assert was thrown
and it was an unrelated passing assert; that is with the assumption you use a
program compiled with debugging flags and you don't rebuild said executable.

 And most importantly of all. I quote "If it ain't broke, don't fix it".

bcs <bcs example.com> writes:

On 01/23/2012 07:13 PM, Era Scarecrow wrote:
 From: "Nick Sabalausky"<a a.a>
 '''
 White space may consist of:
 - A comment between any two tokens.
 - A single space between tokens that, if adjoined would


 All other white space (including \n \r \t \v, etc.) is


 lexical error.
 '''

 With these additions, all valid D code will be so hard


 will ever attempt to read it without first running a


 and once that is standard practice, everyone will see


 preferred style.


 Hah! I like it :)


   It does have a certain amount of sense it makes... but if that were really
an issue, then having your won formatter strip the unneeded spaces and then
re-introducing them back seems trivial, in which case a indentation tool would
be more likely to be used (GNU indent anyone?).

   It does however become an issue regarding debugging, if sources are compiled
against said compacted sources in that way. Everything would be on line 1, and
other such messes. Course if your compiling the sources yourself and run it
through your formatter your fine. But if someone else has their own format and
download the source and reformat it to their format, line 117 may not point to
anything, or point to the wrong object, or worse yet, if an assert was thrown
and it was an unrelated passing assert; that is with the assumption you use a
program compiled with debugging flags and you don't rebuild said executable.

   And most importantly of all. I quote "If it ain't broke, don't fix it".


That's just a tools problem... :b