User Tools

Site Tools


developersguide:codingstyle

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

developersguide:codingstyle [2014/11/11 08:52]
127.0.0.1 external edit
developersguide:codingstyle [2014/11/12 11:17] (current)
lionelsambuc
Line 1: Line 1:
 +====== Coding Style ======
 +
 +Minix is standardizing on the netbsd coding style (based on [[http://​en.wikipedia.org/​wiki/​Kernel_Normal_Form|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 [[http://​git.minix3.org/?​p=minix.git;​a=blob;​f=share/​misc/​style;​hb=HEAD|in the //git// tree]], also available as  **///​usr/​share/​misc/​style//​** in your MINIX machine, and **//​share/​misc/​style//​** in your source tree.
 +
 +====== Older coding style ======
 +
 +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 [[http://​groups.google.com/​group/​comp.os.minix/​msg/​d1170250f03dbf3b&​usg=AFQjCNFcPMJ7uZjoEnBdgoRpC1cEaXO4Xw|comp.os.minix post]] about style:
 +
 +<​code>​
 +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. ​
 +</​code>​
  
developersguide/codingstyle.txt · Last modified: 2014/11/12 11:17 by lionelsambuc