Very interesting to see JPL's coding standards for java. Some obvious requirements: Everything must be compiled with the highest level of warning output, and there must be no warnings or errors; similarly, code must be checked with the most verbose static analysis settings, and there must be no warnings or errors there, either.
Here's one I like: "A nonfinal method should not be called from within a constructor." Rationale: "If such a non-final, non-private method is called in the constructor of the superclass, the call will get dispatched to the sub class, which has not yet been
initialized because classes are initialized top down from superclass to sub class, resulting in unpredictable behavior due to access to uninitialized state."
Note: The full exchange can be found on the LKML but the combined version is cleaner.
Note: The original link, http://kerneltrap.org/node/553/2131, is no
longer available, so I've rehosted the content here.
Submitted by Jeremy on January 13, 2003 - 5:39am
There was a recent discussion on the lkml about the frequent use of "goto"
in Linux kernel code. Drawing perhaps on Edsger Dikjstra's 1968 paper titled
"Go To Statement Considered Harmful", the argument proposed that using goto
will only produce "spaghetti code". A more recent proponent of this theory
being Niklaus Wirth who developed Pascal circa 1970 and its successor,
Modula-2, in 1979.
In the recent thread on the lkml it is made quite clear that the use of goto
in Linux kernel code is well thought out and justified. One such explanation
can be found within chapter 2 of O'Reilly's excellent book, Linux Device
Drivers. It is further explained in the following thread by a number of kernel
developers including Robert Love [dead link redacted],
Rik van Riel [dead link redacted], and Linux creator Linus Torvalds.
An author writes on his blog how systems use goto, and how it's an efficient, clean, and simple way to deal with exceptions.