6 ms·

NASA C Style Guide [pdf]

nickpsecurity 10y ago
Two others of theirs: https://news.ycombinator.com/item?id=12014271 https://news.ycombinator.com/item?id=12014271 http://spinroot.com/gerard/pdf/P10.pdf http://spinroot.com/gerard/pdf/P10.pdf
satysin 10y ago
4 space indentation and not tabs. What would Hendricks say?!
- tscs37 10y ago
  I'd personally say 4 spaces on even indentation levels and tabs everywhere else.
- bunderbunder 10y ago
  Tabs really only works easily when everyone's using the same editor settings. Otherwise, it quickly devolves into a mess. 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.
  - Redoubts 10y ago
    > Spaces really only works easily when everyone uses an editor that can convert presses of the tab key into some number of space characters. Could you show me an editor that doesn't do that?
    - EliRivers 10y ago
      I just finished three years in a job in which I worked on a GUI containing an editor that does not do that.
troycarlson 10y ago
I love seeing internal documents like this that are used at reputable companies. They're both educational and a fun glimpse into how high-performing teams operate.
- c0rtex 10y ago
  In that case, check this out - the NASA Systems Engineering Handbook. It's an impressive beast (only tangentially software-related though). http://www.acq.osd.mil/se/docs/NASA-SP-2007-6105-Rev-1-Final-31Dec2007.pdf http://www.acq.osd.mil/se/docs/NASA-SP-2007-6105-Rev-1-Final...
GnarfGnarf 10y ago
I see the brace goes on the next line, as it should: if(condition) { expression... } instead of the obfuscated form: if(condition) { expression... }
- throwaway_exer 10y ago
  Nonsense.
- _RPM 10y ago
  Statements are inside the brackets as well
- daddykotex 10y ago
  Personally, I prefer the second one. It's more concise and still provide the braces safety.
- mwfunk 10y ago
  What's obfuscated about the second form? It's my personal preference, so I'm sure there's some personal bias there, but one doesn't seem more or less obfuscated than the other one. They are both equally readable to me, but the second seems more compact without sacrificing readability. I can think of other reasons why someone might prefer the first to the second, but reduced obfuscation isn't one of them.
- kchauhan 10y ago
  First one is taking more space then it need to read. I normally use second.
keithnz 10y ago
Looking at their example code.... I find there is a lot of problems, duplicated code, large function with many many obvious simpler functions inlined causing lots of local variable pollution. 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.
- DonaldFisk 10y ago
  There's a difference between style guides, like this, and standards, like MISRA. 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.
  - aidenn0 10y ago
    > 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. 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: https://google.github.io/styleguide/lispguide.xml#EVAL https://google.github.io/styleguide/lispguide.xml#EVAL
thewisenerd 10y ago
How strictly do people writing code have to adhere to styling guides (not just in NASA, but everywhere else too)? 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".
- astonex 10y ago
  Generally, code that does not adhere to the project's style guide will not be merged until it's fixed.
- knodi123 10y ago
  If programming in Ruby, I find that rubocop can enforce our style guide programmatically and impersonally, and it can even be set up with a git commit hook. You can't push ugly syntax! It's not perfect, but it's very good with very little effort.
- technion 10y ago
  There is nothing more annoying than getting a PR that fixed a one line bug, along with someone's editor's autoindent rewriting the entire file the fix was in, because it wanted to change indents. 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.
pmiller2 10y ago
I'm a little disturbed that this doesn't make any mention of when C is even appropriate. I know if I were an astronaut, I'd be concerned about the code running on the vehicle I was on.
- aidenn0 10y ago
  Most high-reliability software is still written in C or other languages in the algol family. For the highest level of assurances, often the binary code must be mapped back to the source code (to reduce the chances of a compiler bug introducing errors), and doing so in languages that are higher-level than C becomes problematic. 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.
  - pjmlp 10y ago
    NASA did use Lisp in the past.
    - aidenn0 10y ago
      Super nit-pick but if you are talking about the DS1, I believe it was JPL under contract for NASA.
0xmohit 10y ago
*average=*total/*count; /* compute the average */ ^ begin comment end comment^ The guide recommends a space after the `/` operator. Does a pair of parenthesis (around the denominator) in such cases hurt that much? -- As an aside, I'd be interested to see their NodeJS Style Guide too. Any pointers?
appletv3 10y ago
Jaguars vs Lions Live Stream Free https://vimeo.com/192355677 https://vimeo.com/192355677

Two others of theirs: https://news.ycombinator.com/item?id=12014271 https://news.ycombinator.com/item?id=12014271 http://spinroot.com/gerard/pdf/P10.pdf http://spinroot.com/gerard/pdf/P10.pdf

satysin 10y ago

4 space indentation and not tabs. What would Hendricks say?!

tscs37 10y ago
I'd personally say 4 spaces on even indentation levels and tabs everywhere else.
bunderbunder 10y ago
Tabs really only works easily when everyone's using the same editor settings. Otherwise, it quickly devolves into a mess. 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.
- Redoubts 10y ago
  > Spaces really only works easily when everyone uses an editor that can convert presses of the tab key into some number of space characters. Could you show me an editor that doesn't do that?
  - EliRivers 10y ago
    I just finished three years in a job in which I worked on a GUI containing an editor that does not do that.

troycarlson 10y ago

I love seeing internal documents like this that are used at reputable companies. They're both educational and a fun glimpse into how high-performing teams operate.

c0rtex 10y ago
In that case, check this out - the NASA Systems Engineering Handbook. It's an impressive beast (only tangentially software-related though). http://www.acq.osd.mil/se/docs/NASA-SP-2007-6105-Rev-1-Final-31Dec2007.pdf http://www.acq.osd.mil/se/docs/NASA-SP-2007-6105-Rev-1-Final...

GnarfGnarf 10y ago

I see the brace goes on the next line, as it should: if(condition) { expression... } instead of the obfuscated form: if(condition) { expression... }

throwaway_exer 10y ago
Nonsense.
_RPM 10y ago
Statements are inside the brackets as well
daddykotex 10y ago
Personally, I prefer the second one. It's more concise and still provide the braces safety.
mwfunk 10y ago
What's obfuscated about the second form? It's my personal preference, so I'm sure there's some personal bias there, but one doesn't seem more or less obfuscated than the other one. They are both equally readable to me, but the second seems more compact without sacrificing readability. I can think of other reasons why someone might prefer the first to the second, but reduced obfuscation isn't one of them.
kchauhan 10y ago
First one is taking more space then it need to read. I normally use second.

keithnz 10y ago

Looking at their example code.... I find there is a lot of problems, duplicated code, large function with many many obvious simpler functions inlined causing lots of local variable pollution. 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.

DonaldFisk 10y ago
There's a difference between style guides, like this, and standards, like MISRA. 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.
- aidenn0 10y ago
  > 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. 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: https://google.github.io/styleguide/lispguide.xml#EVAL https://google.github.io/styleguide/lispguide.xml#EVAL

thewisenerd 10y ago

How strictly do people writing code have to adhere to styling guides (not just in NASA, but everywhere else too)? 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".

astonex 10y ago
Generally, code that does not adhere to the project's style guide will not be merged until it's fixed.
knodi123 10y ago
If programming in Ruby, I find that rubocop can enforce our style guide programmatically and impersonally, and it can even be set up with a git commit hook. You can't push ugly syntax! It's not perfect, but it's very good with very little effort.
technion 10y ago
There is nothing more annoying than getting a PR that fixed a one line bug, along with someone's editor's autoindent rewriting the entire file the fix was in, because it wanted to change indents. 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.

pmiller2 10y ago

I'm a little disturbed that this doesn't make any mention of when C is even appropriate. I know if I were an astronaut, I'd be concerned about the code running on the vehicle I was on.

aidenn0 10y ago
Most high-reliability software is still written in C or other languages in the algol family. For the highest level of assurances, often the binary code must be mapped back to the source code (to reduce the chances of a compiler bug introducing errors), and doing so in languages that are higher-level than C becomes problematic. 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.
- pjmlp 10y ago
  NASA did use Lisp in the past.
  - aidenn0 10y ago
    Super nit-pick but if you are talking about the DS1, I believe it was JPL under contract for NASA.

0xmohit 10y ago

*average=*total/*count; /* compute the average */ ^ begin comment end comment^ The guide recommends a space after the `/` operator. Does a pair of parenthesis (around the denominator) in such cases hurt that much? -- As an aside, I'd be interested to see their NodeJS Style Guide too. Any pointers?

appletv3 10y ago

Jaguars vs Lions Live Stream Free https://vimeo.com/192355677 https://vimeo.com/192355677