Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NASA C Style Guide [pdf]

homepages.inf.ed.ac.uk

Post reply on HN
Print view View original

11–20 of 33 posts

Re: NASA C Style Guide [pdf]

#11

Post by DonaldFisk »

keithnz wrote: post #8

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 cl…

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.

Re: NASA C Style Guide [pdf]

#12

Post by [deleted] »

keithnz wrote: post #8

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 cl…

[deleted]

Re: NASA C Style Guide [pdf]

#14

Post by astonex »

thewisenerd wrote: post #10

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 inv…

Generally, code that does not adhere to the project's style guide will not be merged until it's fixed.

Re: NASA C Style Guide [pdf]

#15

Post by Redoubts »

bunderbunder wrote: post #7
satysin wrote: post #3

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

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.

> 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?

Re: NASA C Style Guide [pdf]

#16

Post by pmiller2 »

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.

Re: NASA C Style Guide [pdf]

#17

Post by aidenn0 »

pmiller2 wrote: post #16

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.

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.

Re: NASA C Style Guide [pdf]

#18

Post by aidenn0 »

DonaldFisk wrote: post #11
keithnz wrote: post #8

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 cl…

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 fol…

> 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

Re: NASA C Style Guide [pdf]

#20

Post by DonaldFisk »

aidenn0 wrote: post #18
DonaldFisk wrote: post #11

Earlier quoted context omitted.

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 fol…

> 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…

We're disagreeing about the meanings of style vs. standards here. I'm using style in the commonly accepted sense, e.g. "hair stylist", "stylish", "all style and no substance."

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.

Post reply on HN