Well, friends, to be able to orient a bit in all that mess we are coding, we all should abide some rules as much as possible. These rules don't strictly apply to frontends and backends, because they should be separated and their authors may be used to use another coding style, which shouldn't be prohibited. One may even deploy contest for most obfuscated backend/frontend (just module from now) ;)). Nevertheless, these rules apply to whole core, which is main IIRC source (really, even if it is not very big today), and you should abide them (with some small tolerance level of course :). Indent level is TWO spaces. No, not eight (==1 tab). You may complain, you may run around crying about so nonsense, but it's just so - i'm used to use two spaces for indentation, from the early ages of Pascal :-), and i won't change it, because i think this is sufficiently orientable. You should avoid long lines, splitting arguments to more lines, don't put more \n's in strings to one line. Also don't put more commands to one line, unless they are really short - same with macro definition. When declaring a function, on first line there's return type and possible modificators of declaration etc. (e.g. static), on second line there's function name, followed by argument list in brackets (in ANSI style), and { separated by space: int foo(int bar, void *baz) { ... } There may be declaration of some variables in the body of a function, plus blank line separating them from the code. Return and various logical groups of code are also separated by a blank line. When you are calling a function, ALWAYS put a space behind ','. When assigning an l-value to a variable, put spaces around equal sign, and do the same in conditions - and if appropriate, group assigments and sub-conditions together by brackets in conditions: if (foo == (bar = (foo == baz)) && (baz = bar)) { ... } (this itself is somewhat evil example, because you should avoid such complicated conditions, or at least explain them properly in comments). You should drop spaces also around operators etc., just observe the code :-). And feed the code with a big bunch of comments ;-). TODO: rewrite whole this in better and organized way ;p Happy hacking! --pasky and fis Another hints: 1. always typecast output of malloc() from (void *) to something better. 2. always put space after typecast 3. don't repeat same (or very similar) (longer) code more times in the source $Id: CodingStyle,v 1.1.1.1 2002/01/24 20:18:18 sembera Exp $