This is insteresting to me especially since this is a 2005 document. Is there a reason why C++ was chosen instead of Ada which to my knowledge was the gold standard for such software ?
A large segment in this article (which is great overall) focuses on this decision. The short summary is "hiring Ada developers was hard and middleware and tooling were difficult to acquire."
While I've moved through a lot of parts of the software industry and may just be out of touch, I actually feel that this may be less the case today. I've seen a lot of school programs focus less on specific languages and frameworks and more on fundamental concepts, and with more "esoteric" languages becoming popular in the mainstream, I actually think hiring Ada developers would be a lot easier today (plus, big industry players like NVIDIA are back to using Ada since AdaCore have been so effective at pushing SPARK, which probably helps too).
My recollection is that it came down to two factors. Pragmatically, the pool of highly skilled C++ programmers was vastly larger and the ecosystem was much more vibrant, so development scaled more easily and had a lower maintenance risk. By 2005 they had empirical evidence that it was possible, albeit more difficult, to build high-reliability software in C++ as the language and tooling matured.
These days they are even more comfortable using C++ than they were back then due to improvements in process, tooling, and language.
> 4.10.9 Inheritance
Class hierarchies are appropriate when run-time selection of implementation is required. If run-time resolution is not required, template parameterization should be considered (templates are better-behaved and faster than virtual functions). Finally, simple independent concepts should be expressed as concrete types. The method selected to express the solution should be commensurate with the complexity of the problem.
I’m a TS + Java person. Is this specific to C++ or is it just due to control freaks with low abstraction skills?
You should see some of the manuals I go through for our some of IoT devices. As far as how Lockheed Martin does it, this quote from the article linked by bri3d answers it:
> MISRA-C was used as the basis for the C applications and a coding standards was developed with the assistance of Bjarne Stroustrup, original author of the C++ language. For both C and C++ Static Code Analysis (SCA) tools are used to ensure that restricted features are not utilized. Arguments about the lack of reliability in either C or C++ are addressed by programming standards restrictions and SCA checks. In truth, this approach is probably more consistent and robust than the manual checks used for previous development efforts including Ada.
Alright that makes far more sense than doing it the "bureaucratic" way. Non-compliant doesn't compile. Must be really annoying working on this codebase hah.
I would argue that it would be very annoying to work on a code base which wasn't like this. Having to spend so much time figuring out where your bottlenecks are and why they are there. Though you would make a fair point in regards to how much code-fascism you need when you try to make C/C++ safer than ADA. I'm sure they didn't come to this conclusion lightly, but the first thing to pop into my head is that it seems odd to do this mainly because of hiring challenges.
But C/C++ certainly did well enough for Lockheed Martin considering it's now one of their principal languages, if not the principal.
It has 9 million lines of code. The coding standards alone are 135 pages. Even with smart people, that sounds challenging to maintain that much C++ (I am surprised no one offered the "rust" advice yet)
It is often that seemingly irrelevant factors play a big role. In this case, a 141 page highly dense (and frankly boring to read) document is in its essence a liability. Engineers get bored too and it is obviously more fun to just code rather than to read a document that might aswell have been written by a lawyer.
This is also why car makers name their cars things like "Jeep Expedition" or "Ford Escape". The name doesn't change the car, but it does make it more exciting.
In this case, a 141 page highly dense (and frankly
boring to read) document is in its essence a liability
So, do you think that the intent was for developers to memorize this document?
Or do you think the expectation was something more reasonable, like using this document as a tool to configure linting tools so that developers could get realtime feedback as they code?
No, that is not what I mean. The efficiency of a piece of knowledge is not only a function of its intrinsic value, but also how easy it is to understand. Sure, the people who are expected to read the document are smart and this is probably the best way to do it, but even Lockheed engineers are fallible.
If anything, the enemy will be defeated before they have had the time to understand the document in case it gets leaked xD
140 pages on coding style. This looks straight out of the CIA handbook for sabotage [1]. I am sure China or Russia have a version of that.
> (12) Multiply paper work in plausible ways. Start duplicate files.
> (13) Multiply the procedures and clearances involved in issuing instructions, pay checks, and so on. See that three people have to approve everything where one would do..
What's the right amount of standards to have when you're writing 9 million lines of code that controls a 30,000lb machine moving through the sky at mach 1 with a human life inside?
Funnily enough, when I look at my codebase, I often think about this handbook. I try intendedly to ascribe it to incompetence but I always have a doubt. If I only listen to my inner voice, I’d fire everyone all the time.
