Re: Coding standards

From: Natt Serrasalmus (Nserrasalmus_at_characoid.com)
Date: 12/30/04 

Date: 29 Dec 2004 21:58:30 EST

"infobahn" <infobahn@btinternet.com> wrote in message
news:cqr5if$1i3$1@sparta.btinternet.com...
> jdallen2000@yahoo.com wrote:
>>
>> Similarly, in C we always write "if (foo(bar))" without
>> debating whether "if( foo (bar))" is better a priori.
>
> Which "we" are you talking about? It doesn't include me.
>
> I write if(foo(bar) != 0)

I find that form really annoying and when I see it in others code. It
suggests to me that the person who wrote it doesn't understand boolean
variables and the C idiom that was established with the C standard library.
The idiom I am referring to is that functions should return a value that
answers the question "Did anything go wrong and if so what was it?". By that
idiom then it should be obvious to any C programmer worth their pay that

if(strcmp(string1, string2))

means "Did anything go wrong (not match up) when comparing these two
strings?" (if I wanted to know how far off they were I'd save the return
value to a variable and evaluate that, but rarely does anyone ever care how
far off the comparison was, other functions may have more interesting
non-zero return codes.)

This form also encourages the early exit from a function:

if(strcmp(string1, string2))
    return;

If you doubt me, look at K&R where you can find numerous examples of this
form and the early exit from functions.

This may seem awkward at first, but you get used to it. You should also get
used to writing your own functions in the same idiom, such that they return
zero for success and non-zero (with a value that indicates the level of
failure) for failure. This will preserve the idiom throughout the code.

A similar form that is particularly annoying is

if(foo(bar) == TRUE) /* where true is a macro defined as some non-zero
value */
{
    (indented code for the entire rest of the function)
}
return somestatusvariable;

when it should be

if(!foo(bar))
    return NONZEROSTATUSVALUE;
(code for the entire rest of the function now not indented so far)

(note also that some may have different notions as to what TRUE should be
defined as: -1, 1 etc. which makes the test against TRUE not just
idiomatically awkward, but potentially dangerous.)

Even worse is

if(a == b)
{
    c = TRUE;
}
else
{
    c = FALSE;
}

which should be

c = a == b;

or even worse than that

if(a == b)
{
    c = FALSE;
}
else
{
    c = TRUE;
}

which should be

c = !(a == b);

Some of you may be laughing at these last two examples, but don't. I've seen
it too many times that it's not funny any more.

>> Because the C language and its programmers are flexible and
>> forgiving, some people may not realize that C white-space rules
>> are standardized,
>
> But they are not.
>
> > but the True Style for Coding C is no secret:
>
> and no standard, either.
>
>> you can look at programming examples from Bill Joy or almost any
>> of the Great Names. Here's a small fragment, essentially in
>> True Style, from the Linux kernel:
>>
>> if (!cap_issubset(inheritable,
>> cap_combine(target->cap_inheritable,
>> current->cap_permitted))) {
>> goto out;
>> }
>>
>> In addition to showing the proper placement of braces,
>
> Hardly. It's a common style, but its mindshare seems to be diminishing.

I hope its mindshare is dimishing. I would have written the above as:

if (!cap_issubset(inheritable,
                           cap_combine(target->cap_inheritable,
                                                 current->cap_permitted)))
    goto out;

This way arguments to functions are lined up. There's no need for any braces
at all, so leave them out leaving fewer braces to worry about which ones
match which. The "goto out" statement could probably be a return statement
or a few cleanup statements (freeing pointers?) and a return statement (in
which case then braces would be needed and I'd prefer to see them lined up).

>
>
> this example
>> is interesting because of the way a long expression is broken
>> into multiple lines, with spacing used to make a nested parameter
>> list more readable. (I mightn't do it quite like this, but only
>> because I mostly stick to TAB's for extended spacing.)
>
> Readable? I don't think so. I'd simplify the expression, tidy up
> the white space, and fix the flow control. Then, maybe, it would
> be readable.
>
>> I know almost nothing about the `indent' utility. Can it produce
>> the spacing above automatically? And suppress it when shorter
>> names make it unnecessary? I know about `#ifndef lint'; is there
>> some sort of `#ifndef indent' when one wants to preserve a helpful
>> white-space arrangement?
>
> The whole point of indent is that you run code through it to
> convert it to your style, making it easier for you to read.
> Then, if you need to check it back into CVS, you run the
> code through it again, this time to convert it to the house
> style. That way, you don't screw up diff with mere whitespace
> changes, and everyone's happy. Bye bye holy war.

I do agree with you on that.

Relevant Pages

  • Re: oscillator
    ... Read other peoples code and learn to indent and use your ... braces clearly and consistently. ... consistent. ... As to level of understanding, I don't profess to be a C expert or I ...
    (comp.lang.c)
  • Re: Format C# Braces in IDE?
    ... > {// inline as indicated ... several suboptions under Formatting that affect how C# code is formatted. ... Check all options under New Lines->New line options for braces. ... Check "Indent block contents" under Indentation and uncheck "Indent open ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Braces or not [Re: cat]
    ... BUT - it is appreciably harder to remember to add them later on ... I used to actually always put the braces in. ... placing the cursor in the new linedirectly under the 'l' from while, ... so new indent is done, ...
    (comp.lang.c)
  • Re: strcpy warning
    ... > habit I picked up from Perl, which requires the braces, but I find it ... indent the body a full level. ... have a harder time with other people's code than I might if I just ... so I might as well be consistent. ...
    (comp.lang.c)