GNU indent.
We tried to restore things to the original style, mostly. There is
-one noteable change: basic indentation is now four spaces. Restoring
+one notable change: basic indentation is now four spaces. Restoring
the original eight spaces would have resulted in many more long lines,
which would have to be broken by indent. Since indent isn't good at
breaking lines tastefully, we reluctantly chose four instead.
screws up tabs. Such changes make it much harder to figure out who
changed what and when.
-Tab character use
+TAB character use
-Whether you use tab characters or not doesn't really matter that much,
-but tab stops are every eight characters, period.
+Whether you use TAB characters or not doesn't really matter that much,
+but TAB stops are every eight characters, period.
Indentation, placement of braces, function name
You are encouraged to format multi-line comments like this:
/*
- * Please use complete sentences, with proper grammer,
+ * Please use complete sentences, with proper grammar,
* capitalization and punctuation. Use two spaces between
* sentences.
*/
typedef struct foo foo;
-Yes, this is incompatble with C++. Reducing the number of names for
+Yes, this is incompatible with C++. Reducing the number of names for
the same thing is more useful than compatibility to a programming
language we don't use.
Factor out common code
-Do not gratuitiously duplicate code! Ken Stevens said it well, and
+Do not gratuitously duplicate code! Ken Stevens said it well, and
it's as relevant as ever:
Cut-and-Paste coding is by far the biggest problem that the current
copy), and yielding the processor, which lets other threads update
the object you copied.
- Therefore, you have to reget after a possible invalidation, and deal
- with changes. In particular, if you checked whether the object is
- suitable for a task, you need to check again after regetting it. If
- you can afford to bail out when something changed, use
+ Therefore, you have to re-get after a possible invalidation, and
+ deal with changes. In particular, if you checked whether the object
+ is suitable for a task, you need to check again after re-getting it.
+ If you can afford to bail out when something changed, use
check_FOO_ok().
Function comments should state what objects the function can update.
Unfortunately, they generally don't.
- It's best to keep puts close to gets, both in runtime and in the
+ It's best to keep puts close to gets, both at runtime and in the
source code.
* Bmaps have special access functions.