However, I've only had horrible experiences trying to read the BSDs' kernel code. There are way too many statements like "mst_fqd->f_do_skb((struct mfq_t *) q);"
sys/queue.h is also provided in all Linux systems.
Easy to use, type-checked by the compiler and a lot faster than a "generic" linked list with pointers to the data. Here, the next/previous pointers get embedded in the payload struct itself.
https://www.kernel.org/doc/Documentation/CodingStyle
Example: Why is the comment style different in net/? It seems to serve no obvious purpose.
Too many cooks :-)
These non-functional commits happen more in areas under active development, while established and inactive projects with less than enough watching eyes want to avoid this kind of non-essential changes.
Like the Linux kernel style, this is essentially K&R style, and the style most of Unix was written in.
On the Linux side, Debian tends to support manpages better than others (they're required by Policy, though they're not release-critical).
[1]: https://github.com/ninjin/ppod/tree/master/hck/openbsd_manpa...
sure
for ()
foo
saves you a line, but it's a bug waiting to happen. for () foo;
Makes it clear it's ONE statement. At least for me..."In function prototypes, include parameter names with their data types. Although this is not required by the C language, it is preferred in Linux because it is a simple way to add valuable information for the reader."
OpenBSD enforces this:
"Prototypes should not have variable names associated with the types; i.e., void function(int); not: void function(int a);"
Instead of letting the code tell the parameters' purposes, this now has to be deduced from informal descriptions, or the function definition in some .c file.
//decl in the header
int pow(int exponent, int base);
if you only look at the header you might think that the arguments are one way, but //actual definition
int pow(int base, int exponent){
//math is correct but base <-> exponent..
}
i'm not saying i agree with this at all - it's a contrived example..! void<tab>function(int);
A cleaner option is "tabs for indentation, spaces for alignment", but with tabs allowed at the beginning of line only. This way opening a file in an editor with a different tab size will still preserve the alignment of the parts.