This shows you the differences between two versions of the page.
releases:3.2.0:developersguide:codingstyle [2014/11/11 14:52] 127.0.0.1 external edit |
releases:3.2.0:developersguide:codingstyle [2014/11/14 17:37] (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> | ||