I absolutely agree. SO should be a starting point for research.

I absolutely agree. I also use Google a lot to search the manual.

Yeah it's more like Googling StackOverflow has replaced reading the manual.

I had to write a geo-localization software for a satellite during my bachelor

That's pretty awesome.

I definitely agree; I would not want to use C for critical situations. So many times I've had strange behavior happen, but absolutely no warnings are crashing. C just makes it too easy shoot yourself in the foot and not even know it. But on the other hand, NASA needs low-level access to hardware (to interface with payloads, etc) and they need a lightweight programming language that's available on a lot of architectures. This really limits the languages they can use. At least these guidelines make writing in C safer.

I guess I'm out of the loop. Did something bad happen at SpaceX due to poor coding?

Thanks for the reply. I've done "Hello, World!" And basic syntax in Go but never a big project in it. I've yet to come up with a good project idea that would directly benefit from Go. I do like the allure of a safe system-level C-like language though.

That's for pointing that out. I should have read and linked the source PDF rather than this article. Oh well.

Go looks interesting. I'd probably use it more if more companies were looking for it. Currently I'm a student focusing my efforts on C, Java, and Python, because everyone wants those.

Well said! It would be a frustration but definitely ensures safety where it's most needed.

Yeah, it certainly makes sense under the circumstances. A lot of these rules seem restrictive at first, but after thinking about them for a while they begin to make perfect sense.

I certainly agree with you, when it comes to while loops. Most notably, the main loop for a given application may never exit if the user never exits the program, as you mentioned. It would be silly for your application to just spontaneously exit so that you can enforce an upper bound.

Makes sense when it comes to calculations, though. Especially in functional programming, every function should either be able to determine the return value or realize it's caught in an infinite loop and exit.

Interesting. Good point that one should be breaking a function into subfunctions for readability. Reminds me of the law that every function/variable/class should be responsible for one things and one thing only.

That's actually a really good point. Properly formatting, documenting, and testing code is probably a lot more important than a clever solution.

There are certainly some of these I wouldn't follow 100% when writing user-end desktop software because they seem too restrictive. For example, keeping functions to less than 60 lines and having at least 2 assertions per function seems unnecessary, and doesn't necessarily mean the code is safer. Outright banning recursion would also make a lot of data structures algorithms that much more confusing.

But I can see why, when the code is needed to ensure the safety of astronauts under extremely dangerous conditions, one would want such strict rules. And certainly a lot of these rules can cut down on erroneously behavior. For example, dynamically allocated memory and abuse of pointers are often a cause for memory leaks leading to undefined behavior. By banning them, these rules make it less likely to be an issue. Further, good assertions will be able to throw an error when such a leak occurs, leading to exceptional circumstances. It also seems most of these rules are there to prevent strange behavior which can happen in C but is already restricted in other languages (ie, Java doesn't even have pointers).

Yeah, Matlab is really big with engineers, especially control systems and signal processing. I wish more would use Python instead, but I can understand the appeal of Matlab for those to whom programming is a means and not an end. It's really easy to program and Matlab, even easier than Python.