"Bill Cox" <bill@viasic.com> wrote in message news:3E34038A.5020901@viasic.com...
> The while loop thing is pretty minor.  My need for the extension to the while loop is somewhat self-imposed.  At work, we have many rules for how to write code.  You can't use break, continue, or goto, and you can't put assignments in conditions.  To get around the problem, we use the C pre-processor:

I can understand the ban on goto's and assignments, but not the ban on break and continue. I've seen code that didn't use break and continue, and it tended to be more complex as a result (and hence more prone to bugs).

In the end, I suspect you'll find such macros that create alternate syntax are more trouble than they are worth (the code won't be readable to other programmers, nor any editors / browsers / parsers that try to extract information by reading source text). I used similar things for a while, and wound up editting them all out.

In article <b1n5st$it3$2@digitaldaemon.com>, Walter says...
>
>
>"Bill Cox" <bill@viasic.com> wrote in message news:3E34038A.5020901@viasic.com...
>> The while loop thing is pretty minor.  My need for the extension to the while loop is somewhat self-imposed.  At work, we have many rules for how to write code.  You can't use break, continue, or goto, and you can't put assignments in conditions.  To get around the problem, we use the C pre-processor:
>
>I can understand the ban on goto's and assignments, but not the ban on break and continue. I've seen code that didn't use break and continue, and it tended to be more complex as a result (and hence more prone to bugs).
>
>In the end, I suspect you'll find such macros that create alternate syntax are more trouble than they are worth (the code won't be readable to other programmers, nor any editors / browsers / parsers that try to extract information by reading source text). I used similar things for a while, and wound up editting them all out.

Hi, Walter.

The rules we're using have evolved over probably 20 years now and at multiple companies, but change when we find a need.  The ban on break and continue is about 12 years old, and seems to have had broad support over this term.  I agree that these can help make code clearer.  The only downside is that inexperienced programmers (or those who are a bit too creative) can make a mess with them.

The most uncommon aspect of our coding environment is that programmers share code daily.  Everyone writes code that looks good to everyone else, and anyone can easily read anyone else's code.  To get there, the coding rules are a bit on the strict side.

Even without our ban on break and continue, I'd argue that the do {...} while(condition) {...} loop is nice.  It seems to simplify a parser, rather than complicate it, and it's handy quite often.  I bet if you tried it for a while, you'd become a fan.

I apriciate your feedback, but don't work too hard.  I'd feel guilty if you wasted time replying to silly feature requests like this one, rather than doing the real work of making D fly.

Bill