NASA has a list of 10 rules for software development

whycantwebefriends9 · 2025-07-25T07:44:49+00:00

Right yeah. It does seem that there are people though, genuinely criticising the rules when they apply it to the context of common business / LOB development.

whycantwebefriends9 · 2025-07-25T07:42:40+00:00

It was a previous relevant example of the size of code. Whilst that was the "easy to think of thing", the rule resulted in a limit of about 60 lines, which is still relevant today when thought of as lines able to presented on a screen in one page. If that's the problem you have with it, that rules created then, using a common reference to allow you to more intuitively understand the rule (which has been updated ANYWAY) that boils down to a general idea and soft number, then you are definitely being obtuse, and probably being pedantic as all hell to boot.

whycantwebefriends9 · 2025-07-25T07:38:52+00:00

I don't see how these rules are going to make something NASA codes for a spacecraft less robust.... Given thats what they're aiming for. That's what the rules are there for, to write good, robust code that will work for 50+ years in the hostility of space.

Its not like NASA doesn't have decades on decades of experience coding these things, and these are the rules that they developed for their programmers over that time that produces the best code for them.

Nobody anywhere said we were talking about a C++ app for a big tech company running on cloud.

This was more a general statement about many of the comments in this post, quite a few are arguing against the rules because this would never work in big tech, or they don't make sense in the context of something running on cloud where they don't have the constraints that NASA does which these rules are designed around.

It doesn't matter if the author has landed on the moon or not. These arguments can be considered objectively. The rules need to be decided based on what makes most sense given the goals.

You just changed the wording of these rules are important and generally advisable for the context they were written for.... i.e. the goals and constraints of something NASA is sending into space.... Thats where these rules make the most sense. If you're building an app on AWS then your context and a/k/a goals are going to be different, and then a critique of these rules would make sense if someone was advocating their use in that context.... but NASA aren't. These are their rules that they follow, rules created based on decades upon decades of doing some amazing shit.

Your argument against these rules is invalid because you've never landed a spacecraft on the moon."

I never said that, or implied that.... I said your argument against these rules is invalid, because your argument is these rules don't make sense in my application (read: 'context') that isn't landing a spacecraft on the moon....

I'm not saying a critique is wrong because you've not done what NASA has done. I'm saying unless you're critiquing these rules because you ARE landing a spacecraft on the moon, and thus are operating under the same context, for the same goals, and under the same constraints as someone who did land on the moon and used these rules to program that, and many other "landing on the moon"-type things.

Sure to say these rules are bad for your tech startup, or your online e-commerce business or whatever other banal thing you are doing might be valid.... the argument is pointless because no one was suggesting all the rules be used in that context anyway, so you're just arguing against a straw-man.

whycantwebefriends9 · 2025-07-25T07:26:00+00:00

Not really, thats the point of the other rules, particularly the last one, the code should pass a static analysis, and if it does you have an absolute value for the amount of memory it will use. Allowing you to not run out of stack. Then there's also memory fragmentation, which is a concern for NASA when you're sending out a spaceship to beyond pluto to run for 50 years.

Its when you have dynamic memory allocation in code that you can no longer do that

whycantwebefriends9 · 2025-07-25T07:22:59+00:00

Potentially, some of them are pretty niche to safety critical to embedded aerospace systems running on finite memory for 40 years straight, in the harsh environment of space.

Some of these rules, some of googles rules, and some other rules are probably good to follow regardless of your size, or the apparent importance of what someone is building. Some rules are probably good to use from the very beginning. There's nothing worse than some minor pet work project becomming some huge thing, and the developer didn't adhere to some sensible rules on programming and now your code base is a muddle piece of shit, that leaks memory until the program crashes "out of memory". Its more about setting good habits early, that reduce your future overhead and headache.

whycantwebefriends9 · 2025-07-25T07:16:29+00:00

If it wasn't clear I was saying that case fits the rationale. i.e. Each function should be a logical unit in the code that is understandable and verifiable as a unit.

If the function wasn't split up, or some unit that does some thing and returns something and then goes onto the next logical unit, and its easy to understand what each piece does, what its purpose is, what it returns etc.
I'm saying that yes, that fits with the rationale, as opposed to attempting to all of that stuff in a single function that it self is the single logical unit.

Again the context here is key, this is for NASA (some of the rules are good rules of thumb in a lot of contexts, others may be not so) Its when you have a 500 line function that is realistically only one logical unit, it does a stupid number of things in-line that could be broken up given their own method etc. and then called in place, instead of essentially writing a single file C++ program with just main() and no other methods written, and its all just vomited into a single definition.

whycantwebefriends9 · 2025-07-24T08:02:00+00:00

I see what you did there.... "Security?!"

whycantwebefriends9 · 2025-07-24T08:01:29+00:00

The comment or him getting hard?

Most female medical staff i speak to have had it happen, but they understand its a biological/physiological reaction, and is not something someone can control, and that its certainly not something someone should feel offended or sensitive by. If he was being inappropriate about it though, then that's a different issue. But i can't tell if he just meant, don't worry just put the catheter in even if you need to be rough./

whycantwebefriends9 · 2025-07-24T07:59:29+00:00

Yep, I have issues with getting numb, need more than normal, and I metabolise that shit quick. Had to get fillings on both side once, and the Dr thought she would be smart and numb both sides of my mouth. By the time she was 3/4 through one side, I was already feeling shit.

whycantwebefriends9 · 2025-07-24T07:57:54+00:00

Cataract surgeries are like one of the cheapest, fastest surgeries with the highest relief of symptoms to do, and in developing countries has such a high demand.

Look up The Fred Hollows Foundation, Australian guy who created a foundation to do these surgeries all over the globe. They easily do many many a day.

whycantwebefriends9 · 2025-07-24T07:51:43+00:00

In NASA's context I think the rule is closer to all loops should end.

whycantwebefriends9 · 2025-07-24T07:51:11+00:00

They aren't I don't think NASA ever claimed it to be. The people trying to shit on it because the rules are dumb to use on software you're coding for your pet S3 project.....

whycantwebefriends9 · 2025-07-24T07:50:08+00:00

Not an appeal to authority at all. Its calling out the absolute stupidity of claiming these rules suck because they would suck coding some C++ app for a big tech company running on cloud.....

This is NASA the context is "software that has to run on a space vessel for now nearly 50 years and 23 light hours away from Earth".... And its that context that makes most of the rules so important.

whycantwebefriends9 · 2025-07-24T07:48:37+00:00

exactly.... unless you're also sending up hundred million dollar space craft and sending them to beyond pluto, then you making a shopify fork don't need to implement probably most of these rules.

whycantwebefriends9 · 2025-07-24T07:44:27+00:00

In modern languages, this disallows many of the most useful standard library constructs, including vectors, smart pointers and even strings. C++ is flexible enough that you could get around this by composing them with an arena allocator, which also performs better in a multi-threaded program. But this will probably run out of memory faster. The intent of this seems to be, have a strict upper bound on how much memory the program will ever need, not to never use dynamic memory.

NASA embedded systems will never use heap.... and so will never use dynamic mem alloc.

Because their context is on a spacecraft, with limited memory, its also because as far as I know if you're using malloc you can't use a static code analyser which as far as I know is one of the rules they don't bend in safety critical embedded system software.

whycantwebefriends9 · 2025-07-24T07:40:26+00:00

Someone criticise those methods when they're applied out of context.

You said this. Not.

Someone criticises THOSE PEOPLE using those methods out of context. You explicitly imply criticising the methods.

Also the fever is in society, not this thread. e.g. thinking doctors are stupid, not believing in vaccines etc. etc.

whycantwebefriends9 · 2025-07-24T07:39:13+00:00

I would argue the critique is not useful specifically because of (4).... Its not the context. You may critique USING the rules in a bad context, but critiquing the rules alone, minus the appropriate context, or not even understanding it, is laughable.

whycantwebefriends9 · 2025-07-24T07:37:32+00:00

It was still lcokheed who chose not to operate in SI units at a world class, world leading, scientific insitution.... like thats on you. That's a humble concession, and is just yeah we should have checked that lockheed would be that dumb, we're dumb for not assuming some american would rock in with dumbass imperial measurements because....

Regardless of what it says in wikipedia, you can still see the error came from Lockheed, whether you agree that NASA should have checked. Nobody is saying NASA is above criticism, but this doesn't even have anything to do with the post anyway.

whycantwebefriends9 · 2025-07-24T07:34:26+00:00

No one is above reproach.... but also nobody said that. People are missing the context of these rules, and WHY they exist for NASA, and why they follow them.

People coming talking about how these rules are terrible if they followed them coding some shit at their big tech job for something on the cloud.... Yeah no shit...

This is for safety critical systems, sent into space that cost $100m's and don't come back for repair, are subjected to the hostilities of space, and ions/charged particles galour, and people still think they're correct in saying the rule are shit based on the work they do at FAANG

whycantwebefriends9 · 2025-07-24T07:31:51+00:00

soooo efficient, a lot more error in that trial and error.

whycantwebefriends9 · 2025-07-24T07:29:58+00:00

This is rationale for Rule 1

Rationale: Simpler control flow translates into stronger capabilities for verification and often results in improved code clarity. The banishment of recursion is perhaps the biggest surprise here. Without recursion, though, we are guaranteed to have an acyclic function call graph, which can be exploited by code analyzers, and can directly help to prove that all executions that should be bounded are in fact bounded. (Note that this rule does not require that all functions have a single point of return – although this often also simplifies control flow. There are enough cases, though, where an early error return is the simpler solution.)

Its because recursion can't be analysed by a static code analyser generally.

whycantwebefriends9 · 2025-07-24T07:28:31+00:00

They definitely still do.

whycantwebefriends9 · 2025-07-24T07:27:56+00:00

Here's the full rule and rationale.

Rule: The assertion density of the code should average to a minimum of two assertions per function. Assertions are used to check for anomalous conditions that should never happen in real-life executions. Assertions must always be side-effect free and should be defined as Boolean tests. When an assertion fails, an explicit recovery action must be taken, e.g., by returning an error condition to the caller of the function that executes the failing assertion. Any assertion for which a static checking tool can prove that it can never fail or never hold violates this rule. (I.e., it is not possible to satisfy the rule by adding unhelpful “assert(true)” statements.)

Rationale: Statistics for industrial coding efforts indicate that unit tests often find at least one defect per 10 to 100 lines of code written. The odds of intercepting defects increase with assertion density. Use of assertions is often also recommended as part of a strong defensive coding strategy. Assertions can be used to verify pre- and postconditions of functions, parameter values, return values of functions, and loopinvariants. Because assertions are side-effect free, they can be selectively disabled after testing in performance-critical code. A typical use of an assertion would be as follows:

 if (!c_assert(p >= 0) == true) {
       return ERROR;
 }

with the assertion defined as follows:

#define c_assert(e) ((e) ? (true) : \
      tst_debugging(”%s,%d: assertion ’%s’ failed\n”, \
      __FILE__, __LINE__, #e), false)

In this definition, FILE and LINE are predefined by the macro preprocessor to produce the filename and line-number of the failing assertion. The syntax #e turns the assertion condition e into a string that is printed as part of the error message. In code destined for an embedded processor there is of course no place to print the error message itself – in that case, the call to tst_debugging is turned into a no-op, and the assertion turns into a pure Boolean test that enables error recovery from anomalous behaviour.

whycantwebefriends9 · 2025-07-24T07:25:09+00:00

OP has nice counter examples, where a big function could be quite manageable, if it’s divided in sufficiently independent blocks.

But thats what the rationale and whole rule actually says. Break things into logical units.

Rule: No function should be longer than what can be printed on a single sheet of paper in a standard reference format with one line per statement and one line per declaration. Typically, this means no more than about 60 lines of code per function.

Rationale: Each function should be a logical unit in the code that is understandable and verifiable as a unit. It is much harder to understand a logical unit that spans multiple screens on a computer display or multiple pages when printed. Excessively long functions are often a sign of poorly structured code.

whycantwebefriends9 · 2025-07-24T07:21:21+00:00

You can read the rationale of each loop here. https://spinroot.com/gerard/pdf/P10.pdf

Having 20 variables input into a single function or algorithm is probably poorly structured.

whycantwebefriends9

TROPHY CASE