Mars Rover Curiosity C Coding Standard

[zach]

I found this interesting.

I know this probably isn't the place and site discussion would be more suited, but I propose a thread for general software development banter, much similar to f=48's general photography banter.

It would be a thread for posting interesting articles, whitepapers, blogs etc related to development. I'm not sure how much traffic it would attract but I'm willing to copy-pasta interesting stuff I see and discuss.

[SaTaN]

hardly surprising, the target isnt exactly a cheap device which can be thrown away or reset if it crashes

[SLATYE]

It'd be interesting to see what the performance difference is between highly-optimised code (ignoring these guidelines) and code that rigidly sticks to the guidelines. Lots of assertions and sanity checks must take a fair bit of processing power.

Not that it matters for Curiosity - it moves slowly anyway and it's got a relatively large amount of processing power available.

[Zoltag]

Interesting to note that even sticking to these standards, the number of bugs found in the code wasnt noticeably reduced:

http://www.theregister.co.uk/2012/08...ware_coverity/

Roughly 2,000 bugs were zapped in the rover's code...For a project with 2 million lines of code, it would therefore not be unusual for Coverity to be able to find about 2,000 defects

[SLATYE]

Most of the requirements aren't really to prevent mistakes in the code - humans make mistakes in any code, and this is no different.

Instead they're designed so that mistakes in the code don't have far-reaching consequences. For example, a mistake might cause an incorrect result, but it won't cause an infinite loop because loops have verifiable bounds. It might cause an incorrect input to one function, but the function will immediately throw an error rather than continuing to propagate the incorrect data. This system also allows the code to be more easily checked by automated tools; it's very possible that other software would have 2000 bugs that were found plus another 500 that were never spotted because there's no straightforward way to check.

[Foliage]

A bug is better than a bug that causes the software to crash or require a watchdog timer to reset, that is all that these guidelines really prevent.

[Jay]

Brings me back to systems engineering. It's better to have bugs that fail gracefully than ones that cause total failure, and it's much better to be able to know about the ones that do exist. In complex software it's about impossible to reach zero defects, and as defects approach zero more defects are likely to be reintroduced.

It's also probably for a bureaucratic paper-trail too.

There should be no more than one statement or variable declaration per line. A single exception is the C for-loop, where the three controlling expressions (initialization, loop bound, and increment) can be placed on a single line.

Which you'd normally think is quite trivial.

[aXLe]

If you have time to read it, this is an interesting insight : http://www.fastcompany.com/28121/they-write-right-stuff

[zach]

Originally Posted by Jay

There should be no more than one statement or variable declaration per line. A single exception is the C for-loop, where the three controlling expressions (initialization, loop bound, and increment) can be placed on a single line.

Which you'd normally think is quite trivial.

At least they use C99.

[MoorKhan]

I linked the coding standards document in the curiosity science thread too, but it didn't see much discussion there.

Originally Posted by Zoltag

Interesting to note that even sticking to these standards, the number of bugs found in the code wasnt noticeably reduced:

http://www.theregister.co.uk/2012/08...ware_coverity/

That might be a little misleading, as Coverity mostly deal with big name companies that presumably have quite stringent standards of their own. Coverity apparently charge quite a bit (and bill per line of code), so their clients are unlikely to be companies writing code without solid standards already in place.

The rationale behind the power of ten rule 5 (assertion density), indicates that in typical industrial code one defect is found every 10 to 100 lines of code - rather than every 1000 as Coverity reports in that article. So going on the 10-100 figure the number of bugs has been significantly reduced.