any value in a standard for defining bit flags?

[Rob Landley]

On Monday 03 July 2006 5:19 am, Robert P. J. Day wrote:
> i *did* say i didn't feel like doing any real work. :-)  i wouldn't
> suggest *enforcing* any kind of standard like that, but maybe just a
> list of recommended or suggested standards for an applet coding style?

Ah, we get back to the coding style issue.

Here's the busybox coding style I actually pay attention to:

1) We use tabs for indents.  These tabs are 4 spaces.  Deal with it.

2) We declare functions vaguely like this:
void blah(thingy *blah)
{
  stuff
}

We don't put the the return type the previous line (ctags exists, if you care 
learn to use it).

Except for function declarations, the { is on the same line as things like if 
and for, and "} else" is also common.  The exception is when you have 
something like an if statement or for loop that goes more than one line, then 
the { at the end of it should be on its own line.

I tend to prefer
    if (blah) thingy();
to
    if (blah)
        thingy();
both of which I prefer to
    if (blah) {
        thingy();
    }

But I'll live with any of them as long as you're consistent.

3) Consistency is per file, not busybox wide.  The purpose of making code look 
like the code around it is so you can _read_ it.  (If you can't read multiple 
styles of C code, you won't get very far as a programmer.)  We do some style 
cleanups, but not that much.  (Yes, they do occasionally introduce bugs, and 
it can be a real pain to track unrelated changes past them.)

4) The screen is 80 characters wide.  Deal with it.  You can leak a little if 
you've got a good reason, but generally you should break lines at 80 chars 
when it's reasonably feasible to do so.  (Hey, the linux kernel has 80 chars 
wide _and_ a tabstop of 8.  We've got it easy in comparison.)

5) For no readily apparent reason, we have gratuitous spaces distinguishing 
tests and loops from functions, ala "if (blah)" and "for (blah)" 
vs "function(blah)".  If you don't know your test and loop keywords you 
really shouldn't be banging on busybox, but enough people screamed that I 
just want to be consistent here.

We also have gratuitous spaces all over the place like "x = y" and
"blah(x, y);"  (This was not my doing, but in the interests of consistency 
I've bowed to pressure on this one to the point where I'll actually clean 
existing code up to look like this.  I want it to be consistent more than 
anything else.)

6) We use c99, including things like // comments and uint32_t.

> p.s.  the other reason i prefer a bit of a standard in this case is to
> visually distinguish when someone is using, say, the value 1024 as
> maybe a buffer size, or using it as a bit mask.  if i see "1024", i
> might conclude it's defining an array to hold a block.  if, however, i
> see "0x400", i'd more likely assume this was meant as a bit setting.
> it might occasionally make it easier to spot typoes.  but i'm not
> going to lose any sleep over this.

What we actually might want in that case is a naming convention for option 
flags then.  Not a type of constant only used contextually.  (Ok, I admit 
that if you see octal, it's probably permission flags, but that's only 
because nobody really uses octal for anything else.  Except maybe literal 
character escapes. :)

Rob
-- 
Never bet against the cheap plastic solution.