This document describes the coding style currently used in libevent. All changes or patches for the library should adhere to this style.
Standard indentation is two spaces. It is prefered, but not required, that sequences of 8 contiguous spaces be replaced by tab characters ("\t"). There should be no spaces between function names and open parenthesis, nor between the close parenthesis and the trailing semicolon. One space should follow every comma, but otherwise there should be no other spaces in function call arguments except as required by other context (calling a function from within the argument list of another, for instance). All comments should be seperated from other statements on the same line by a single space. Control statements such as "if" or "while" should have a space between the statement and the open parenthesis, but again, internal space should be kept to a minimum. Finally, all binary operators should be surrounded by spaces, whereas all unary operators should not be surrounded by spaces.
In summary: Spaces should be kept to a minimum, but this should not be permitted to impact code readability.
In all statements that begin a block, such as "if" or "while," the open brace ("{") must be on the same line as the last line of the "if" expression. Only in functions should an open brace appear on a line by itself. Correspondingly, the close brace ("}") must be on a line by itself, followed only by a semicolon where necessary, except in "do-while" loops, where the "while" portion of the loop control must be on the same line as the close brace. All blocks are to be indented by only two spaces relative to the enclosing block.
The "goto" statement may only be used for error exits where the function must perform some clean-up before returning to its caller. Its use otherwise is prohibited. If you think you need to use it in some other context, trust me, there's another way of doing what you want.
All lines, including comments, must end at or before column 79. If parenthesized statements must be continued, the following line must be indented to line up with the first character position after the last unmatched open parenthesis; otherwise, the following line must be indented by two spaces.
Comments are good. The more comments, the better--as long as they're readable and useful! Document every function, even local or private functions, and try to document the algorithm that the function is using. Avoid using comments starting with the characters "/**" unless you mean to write a so-called documentation comment.
All source and header files should begin with a comment referencing the copyright holder(s), followed by a description of the licensing, followed by "@(#)$Id$". Each line should begin with two asterisks ("*"), and no other text should be on the same lines as the beginning and ending sequences. No other comment in any source file should use two asterisks at the beginning of each line, but comments broken across lines must begin with a single asterisk indented to line up with the first asterisk in the preceeding line.
Don't use any CVS keywords other than "$Id$"; this should only appear in the initial comment and in RCSTAG() and no where else. All source files must use RCSTAG(), and the keyword should always be preceeded by the character sequence "@(#)"--this sequence has special meaning to older variants of the utility program "ident."
Each exported function must be in a file by itself unless it is strongly related to some other function. Each internal, non-local function should be in a file by itself unless it is strongly related to some other function. This allows statically-linked programs to include the minimum amount of library code possible.
Try to avoid long functions. If it's more than two or three 24-line pages long, it's probably too long. Break such functions up into a handful of helper functions, ideally local to that file. Any non-static user-visible function should begin with a prefix unique to the library, followed by an underscore character ("_"), followed by the rest of the function name. Do not mix case--this is C, not C++. If a function is internal, but cannot be made static, use an underscore character, followed by the library prefix, followed by another underscore, followed by the rest of the function name. Avoid exporting variables whenever possible.