Some of the Rules to Develop Safety Critical Code according to NASA
This article is based on the "The Power of Ten" paper written by "Gerard J. Holzmann." Using these rules you will be able show that your software will work as intended.
Rules:-
Use simple Control Flow constructs:- Do not use goto statements or jumping statements, and recursions.
Reasoning:-
Do not use Dynamic Memory Allocation after Initialization
Reasoning:-
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 & one line per declaration.
Reasoning:- A function should be understandable & verifiable. Long functions indicates poorly structured code.
Recommended by LinkedIn
The return value of non-void functions must be checked by each calling function, and the validity of parameters must be checked inside each function.
Reasoning:- Explicit checking whether a value exists or not prevents our program from crashing.
Data objects must be declared at the smallest possible level of scope
Reasoning:- Helps programmer to identify which part of code actually corrupted the memory or induced a bug.
The use of pointers should be restricted.
Reasoning:- Pointers are easily misused, like de-referencing a memory that do not exist. And they can make it hard to analyze the flow of data in our program.
All Code must be compiled with all compiler warnings enabled. All code must compile without any warnings.
Reasoning:- With all compiler warning enabled, the compiler will treat all the warnings as errors which helps programmer to write trivially valid code.