Style (was Re: on goto) [General Programming]

Prev: is this NP-Hard?
Next: An M/M/n queuing model simulation with Object Pascal and my Thread Pool Engine...

From: Keith Thompson on 2 May 2010 00:02

From: Ben Bacarisse on 2 May 2010 08:58

Kenneth Brody <kenbrody(a)spamcop.net> writes:

> On 5/1/2010 1:03 PM, Keith Thompson wrote:
>> Juha Nieminen<nospam(a)thanks.invalid> writes:
>>> In comp.lang.c++ Moi<root(a)invalid.address.org> wrote:
>>>> Personally I tend to use:
>>>>
>>>> for ( begin_expr; test_expr; next_expr) {;}
>>>>
>>>> , which immediately makes clear that the empty loop is intended.
>>>
>>> And causes a compiler warning due to a lone ';' if enough warning flags
>>> are used.
>>
>> It does? A lone semicolon in this context is a null statement, which is
>> perfectly legal. Compilers can certainly warn about anything they like,
>> but I don't see why it would warn about this.
> [...]
>
> Consider:
>
> for ( begin_expr ; test_expr ; next_expr );
> do_something();
>
> The "lone semicolon" could easily be a typo, and not easy to spot at
> times. (Which is sort of what this sub-thread is all about.)

The merits of various styles for empty loop bodies is frequently debated
here, but here's a thought: does it actually matter? Has anyone ever
encountered a hard bug caused by either the accidental inclusion of a
semicolon (thereby excluding the while loop body) or by the omission of
a null body (thereby sucking the following statement into the loop)? I
don't think I ever have. I certainly don't recall one.

I say "hard bug" because (of course) bugs are caused by this issue, one
way or the other, but I imagine that they are always so detrimental to
the intent of the code that they show up at the first test. Such bugs
are not so different from syntax errors -- the compiler tests the syntax
and your own tests test the basic functioning of a code fragment.

Does anyone have a recollection of such a hard to find bug and, if so,
do you recall enough to explain how it came about?

For the record, I have no objection to this being discussed often and at
length; I am just explaining why I find it hard to care. I've used most
of the methods suggested at one time or another, but I was never able to
conclude that one was better than the others.

--
Ben.

From: Richard Harter on 2 May 2010 10:26

On Sun, 02 May 2010 13:58:55 +0100, Ben Bacarisse
<ben.usenet(a)bsb.me.uk> wrote:

>Kenneth Brody <kenbrody(a)spamcop.net> writes:
>
>> On 5/1/2010 1:03 PM, Keith Thompson wrote:
>>> Juha Nieminen<nospam(a)thanks.invalid> writes:
>>>> In comp.lang.c++ Moi<root(a)invalid.address.org> wrote:
>>>>> Personally I tend to use:
>>>>>
>>>>> for ( begin_expr; test_expr; next_expr) {;}
>>>>>
>>>>> , which immediately makes clear that the empty loop is intended.
>>>>
>>>> And causes a compiler warning due to a lone ';' if enough warning flags
>>>> are used.
>>>
>>> It does? A lone semicolon in this context is a null statement, which is
>>> perfectly legal. Compilers can certainly warn about anything they like,
>>> but I don't see why it would warn about this.
>> [...]
>>
>> Consider:
>>
>> for ( begin_expr ; test_expr ; next_expr );
>> do_something();
>>
>> The "lone semicolon" could easily be a typo, and not easy to spot at
>> times. (Which is sort of what this sub-thread is all about.)

On the converse, the lack of a semicolon would be a typo.
Without it the code is not properly indented.

>
>The merits of various styles for empty loop bodies is frequently debated
>here, but here's a thought: does it actually matter? Has anyone ever
>encountered a hard bug caused by either the accidental inclusion of a
>semicolon (thereby excluding the while loop body) or by the omission of
>a null body (thereby sucking the following statement into the loop)? I
>don't think I ever have. I certainly don't recall one.
>
>I say "hard bug" because (of course) bugs are caused by this issue, one
>way or the other, but I imagine that they are always so detrimental to
>the intent of the code that they show up at the first test. Such bugs
>are not so different from syntax errors -- the compiler tests the syntax
>and your own tests test the basic functioning of a code fragment.
>
>Does anyone have a recollection of such a hard to find bug and, if so,
>do you recall enough to explain how it came about?
>
>For the record, I have no objection to this being discussed often and at
>length; I am just explaining why I find it hard to care. I've used most
>of the methods suggested at one time or another, but I was never able to
>conclude that one was better than the others.

What I have seen are bugs caused by not noticing that the
indentation is inconsistent with the code. Thus:

if (rare_condition)
take_special_action();

In the fullness of time our hero adds a statement to the block to
produce:

if (rare_condition_
take_special_action();
increment_error_count();

where the error count is incremented whenever an error occurs in
the system. When the error count gets too high the system goes
into error recovery mode and slows way down. The results are
still correct but the performance degrades. (The example is
contrived but I have seen this sort of thing happen.)

In my view all of these fiddles with an empty loop body are
pointless, and, if anything, make the code harder to read and
offer more room for error.

Richard Harter, cri(a)tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.

From: Ben Bacarisse on 2 May 2010 10:59

cri(a)tiac.net (Richard Harter) writes:

> On Sun, 02 May 2010 13:58:55 +0100, Ben Bacarisse
> <ben.usenet(a)bsb.me.uk> wrote:
<snip>
>> Has anyone ever
>>encountered a hard bug caused by either the accidental inclusion of a
>>semicolon (thereby excluding the while loop body) or by the omission of
>>a null body (thereby sucking the following statement into the loop)? I
>>don't think I ever have. I certainly don't recall one.
<snip>
> What I have seen are bugs caused by not noticing that the
> indentation is inconsistent with the code. Thus:
>
> if (rare_condition)
> take_special_action();
>
> In the fullness of time our hero adds a statement to the block to
> produce:
>
> if (rare_condition) /* corrected typo: missing ) */
> take_special_action();
> increment_error_count();
>
> where the error count is incremented whenever an error occurs in
> the system. When the error count gets too high the system goes
> into error recovery mode and slows way down. The results are
> still correct but the performance degrades. (The example is
> contrived but I have seen this sort of thing happen.)

I agree. I'd say that indentation if more important than how an empty
body is written, but since there are tools to help with this I am not
convinced it is all that significant. Sadly they are separate tools so
they may get forgotten. I'd be happy to see warnings from a compiler
about incorrect indentation because they so often indicate a serious
problem.

<snip>
--
Ben.

From: Andy Champ on 2 May 2010 12:02

Moi wrote:
>
> Personally I tend to use:
>
> for ( begin_expr; test_expr; next_expr) {;}
>
> , which immediately makes clear that the empty loop is intended.
>
> AvK

The "comments are unnecessary" people aren't going to like this but...

for ( begin_expr; test_expr; next_expr) { /* Do nothing */}

for ( begin_expr; test_expr; /* no increment */)
{

}

work for me.

Andy

First | Prev | Next | Last
Pages: 1 2 3 4 5
Prev: is this NP-Hard?
Next: An M/M/n queuing model simulation with Object Pascal and my Thread Pool Engine...