Re: [dpdk-dev] tools brainstorming

[Don Provan <dprovan@bivio.net>]

>NOTE Please avoid, as much as possible, including headers from other headers file. Doing so should be properly explained and justified.

Actually, I think a *failure* to #include other header files that this header file depends on should be what needs explained and justified. It drives me crazy when a header file forces me to figure out what header files it depends on and then forces me to include them in my sources even though my sources don't use them. Especially when #include is such a straightforward way to document the dependency while keeping me out of it.

Or are you only talking about when the header file doesn't depend on the header files its #including? If so, then I'd prefer ruling it out entirely rather than saying it needs to be justified.

>For consistency, getopt(3) should be used to parse options.

I assume this means the getopt() family, and I'd expect getopt_long() to be used normally. (If it were me, I'd *encourage* getopt_long() over getopt().)

>not:: 
> if (!*p)

I'm not sure why you'd bother to rule out this common idiom or the similar NULL pointer check. Are "if (*p)" and "if (p)" also prohibited, or just their negations?

>Values in return statements should be enclosed in parentheses.

Please don't encourage people to have this silly habit. It makes no more sense than insisting variables be set with "x = (-1)".

>static void
> usage()

This has nothing to do with the point being made here in your document, but surely you want to insist on "static void usage(void)", right? In fact, you might mention parameterless functions explicitly in the section on function declarations.

Everything else looks pretty cool. I'm surprised and impressed.
-don provan