Minix is standardizing on the netbsd coding style (based on KNF (Kernel Normal Form)) for new code. Mostly because the NetBSD import trend makes this the logical choice for a standard.

The canonical reference is in the //git// tree, also available as /usr/share/misc/style in your MINIX machine, and share/misc/style in your source tree.

This is for reference only, to see what was once considered beautiful. Do not use these principes in new code.

The policy on the eventual migration from this style to KNF has not been decided yet.

From AST's comp.os.minix post about style:

We haven't had a good religious war since the discussion about the PDP-11 
memory management unit.  Let's give this a try.  There was a recent posting 
of cb (C beautifier).  I am not going to use it because it does not beautify. 
It uglifies, and cu is already taken.  The MINIX kernel, FS, and MM are all 
below.  If anyone feels like writing a cb that makes all program adhere to the 
book style, that would be great.  Other cbs need not apply.  For more details, 
look in the book.  There are 250 pages of examples there.

SAMPLE FUNCTION 
struct inode *get_inode(dev, numb) 
dev_nr dev;                     /* device on which inode resides */ 
inode_nr numb;                  /* inode number */ 
{ 
/* Find a slot in the inode table, load the specified inode into it, and 
  * return a pointer to the slot.  If 'dev' == NO_DEV, just return a free slot. 
  */ 
  register struct inode *rip, *xp; 
  int k, mark; 
  /* Search the inode table both for (dev, numb) and a free slot. */ 
  xp = NIL_INODE; 
        if (rip->i_dev == dev && rip->i_num == numb) { 
                /* This is the inode that we are looking for. */ 
                rip->i_count++; 
                return(rip);    /* (dev, numb) found */ 
        } else { 
                xp++; 
                count++; 
                if (count > N) limit = 1; 
        } 
  for (rip = &inode[0]; rip < inode[MAX]; rip++) { 
        if (rip->i_num == 0) { 
                mark = 1; 
                k = rip - inode; 
        } 
  } 
} 

 1. Function types (e.g., struct inode *) are written on the same line as the 
    function name. 
 2. No spaces before or after parentheses in functions or calls. 
 3. One space after commas in argument lists. 
 4. Each is described by a short comment starting at tab stop 4 (col 33). 
 5. Open curly brace is on a separate line following the argument list; 
 6. Each function starts with a comment in the form of one or more complete 
        -  Multiline comments all contain vertically aligned asterisks. 
 7. Include a blank line after the initial comment. 
 8. All declarations come next.  No inner declarations, e.g. {int x; ...}. 
 9. A blank line after the last declaration. 
10. Initial indentation is two spaces.  Subsequent indentation is at tab stops. 
    This reduces the chance of exceeding 80 characters on a line. 
11. Function bodies are divided into logical sections.  Each section begins 
    with a capitalized full sentence.  Sections are separated by blank lines. 
12. Short if statements are included on a single line. 
13. Long if statements contain the { on the first line.  The closing } is 
    aligned with the if.  If both the then and else parts are multistatement, 
    the } else { is on one line and aligned with the if. 
14. Use { } to enclose any complex statement, even if not required, as in 
    the for statement above. 
15. Where useful, include short comments at the end of statements.  These 
    comments are not whole sentences and do not begin with capital letters. 
    They start at tab stop 4 (col 33) where possible.  They should fit on 
    the line and never run beyond column 80. 
16. In general, leave a space around operators like +, ==, < etc. 
17. Use parentheses to enclose arguments in return statements.