NASA C Style Guide [pdf](homepages.inf.ed.ac.uk) |
NASA C Style Guide [pdf](homepages.inf.ed.ac.uk) |
MISRA is another standard that's popular and I've seen a bunch of code developed using this standard.
But the problem with style guides, they have lots of points that are very agreeable, but it is all undone if you don't have clean well designed code. I've seen too much emphasis on conforming to the style guide (often because of contractual agreements on the developed code). But the more important part of making the code clean gets less attention because it is harder to quantify and harder to enforce via static analysis.
however, that doesn't mean it's a bad thing to have, it's just that conformity to a style guide is a very low bar in terms of quality.
Style is concerned with the appearance of the code, and is largely subjective. Many languages, like Common Lisp and Java, have got this nailed: the same style is used everywhere. In the C world, there are endless arguments about levels of indentation, the position of braces, etc.
Standards ensure that good, safe, coding practices are followed. For C, these are needed for many applications because the language is weakly typed and inherently unsafe in many ways. Other languages, such as Ada, have safety built into the language.
https://www.usenix.org/conference/hotdep12/workshop-program/...
He presents a compelling case for why you should use automated tools to check compliance against coding standards (the standards don't do you any good otherwise).
As far as style goes, pipe your code through indent if you have hangups about formatting. That way you can spend your time on issues that are known to be correlated with risk.
I'm struggling with where to first disagree with this. Some style guides deal only with code appearance, but they can also include things like preferred iteration mechanisms, maximum function lengths or even cyclomatic complexity.
Comon Lisp doesn't even remotely have standardized style; ask a dozen CL programmers how they would perform an operation on each element of a list and you'll get answers including: MAPCAR, MAP, DOLIST, LOOP, ITERATE.
It does have a standard for indentation, which is roughly "however emacs would indent your code" but that breaks down when DSLs get involved (see how different people indent LOOP for an example).
[edit]
One simple example of a style guide entry that is not primarily concerned with the appearance of code. There are dozens more in that one style guide:
I get that coding standards are a good thing and plain-simply following these will produce "readable" and (possibly) maintainable code, but will that make the code any _better/efficient_ ?
Though this does catch some "gotchas" in C, like the if-if-else and the #define trap, I wonder if the Code Review involves a guy rejecting my patches with the comments, "you have missed out guideline 6.4.3.5 defined in page 54".
It's certainly not efficient reading a patch with a +1000/-999 diffstat, hunting for a one line fix. I've had this repeatedly and it's painful. Anyone that noted the existing style wouldn't have let this happen.
http://www.acq.osd.mil/se/docs/NASA-SP-2007-6105-Rev-1-Final...
*average=*total/*count; /* compute the average */
^ begin comment end comment^
--
As an aside, I'd be interested to see their NodeJS Style Guide too. Any pointers?
If someone were to formally verify the correctness of a particular higher-level language implementation, then it would start to become usable. Most GCed languages are out though due to the fact that hard-realtime GC algorithms require an excess of CPU and RAM to run correctly, and vehicles going into space are often several generations of hardware behind, as new radiation-hardened CPUs come out only rarely.
Spaces really only works easily when everyone uses an editor that can convert presses of the tab key into some number of space characters.
The only solution that works easily in all cases is to flatly refuse to collaborate with others.
Could you show me an editor that doesn't do that?
if(condition)
{
expression...
}
if(condition) {
expression...
}It's more concise and still provide the braces safety.
Maximum function lengths and cyclomatic complexity are important but I'd put those under standards.
Lisp gives you a lot of flexibility regarding how you do things, but once you choose a way, that constrains how your code should be laid out, i.e. its style. EMACS indents code in the accepted Lisp style. It doesn't define it. It implements it.
Saying you should avoid eval at run time is a coding standard, not style.
Indeed we are. I'm considering "style guide" as a noun phrase to include many things that you would call standards, and comes from the definition of style "a manner of doing something."
It actually makes me think that there should be a standardized way for including indentation hints. CL's &body in macros is not nearly enough for any kind of complicated DSLs.
That's minor aesthetics anyway. There are always some degrees of freedom in it, but Lisp has historically much less of those than C-like languages.