On 2016-06-24 12:17, Rainer Weikusat wrote:

> Peter Olson <peabo@???> writes:
>>> On June 23, 2016 at 10:48 AM Edward Bartolo <edbarx@???> wrote:
>>>   if (count > 0)
>>>     while(putchar(' ') && --count);

>>
>> I strongly recommend using the continue statement here:
>>

>>       while(putchar(' ') && --count) continue;

>
> I and I strongly recommend against it. The continue has absolutely no
> meaning here which means its only conceivable effect is to puzzle the
> reader. Insofar inline documentation is desired, the way to include it
> are comments, not technically functionless statements at whose intention
> can only be guessed at. Better yet, use a sensible loop:
>
> if (count > 0) while (putchar(' ') && --count);

I could have criticized Edward for mixing the boolean with the action, but that was not my point.

The issue is coding style. There are coding styles which reduce the likelihood of writing bad code, and they should be encouraged. The bare semicolon -> continue is one of them. It has nothing at all to do with what the compiler does. Case in point, don't do i[a] for a[i] even though the compiler treats them identically.

Code is written once (well, maybe more like 1.2 times), but it is read by N >> 1. Encourage clarity.

No reader who is accustomed to seeing the continue statement will be puzzled by it.

>> Another habit I have is to avoid a statement like:
>>

>>     if (abc == 42)

>>
>> and write it as
>>

>>     if (42 == abc)

>>
>> instead.
>
> That's a habit of many people who either believe to be master yoda
> ('Your sister she is') or who believe their heart-felt support for
> Nikolaus Wirth is so important that it trumps writing clear code.
>

>     - compilers usually warn about = in conditions

Hendrik has the edge on me. I didn't learn C until around 1980, when the predominant C compilers I had access to were Whitesmiths C on VAX/VMS and Lattice C for MSDOS (I guess a little later than 1980 :-)

In any case, having good programming habits avoids the time sink of having to fix compiler warning message if they even exist.

I am a fan of -Wall and fixing warnings at the earliest opportunity.

>         - this is an extremely uncommon error

So uncommon that I developed my good programming habit more than 30 years ago.

>         - the inversion doesn't help when both operands are l-values

This is not a problem obviously, you can equally well write it either way. Do you have a counterexample?

> So, program in Algol 60/ Pascal/ Modula/ Oberon or "take your := and
> shove it". The world has moved on.

Can I download your compiler that fixes all my mistakes? I could really use such a tool.

Peter Olson