General Design Ideas

Some general guidelines to follow when writing flight software.

• Avoid dynamic memory allocation as much as possible - calls to "malloc" (in C) or "new" (in C++) should be avoided unless absolutely necessary. There is an inherent danger to allocating memory "on the fly" because you may end up using more than you think, which would at worst terminate the flight program and best do other undefined behaviors. A good way to manage memory that is frequently swapped or rewritten is to allocate a large array of static memory (an array outside of a function) and use memory "dynamically" from that pool. This way if you run out, you won't blow up your heap.
• Functions/Methods that do "things" should return if they were successful - if a function/method is performing a task that could fail (doing any I/O, checking a tolerance, etc.) it should return whether it was successful. This way whatever code is calling it knows and can take the appropriate action and does not just assume every call is successful. It is also important to actually check for these returns if you call a function/method that returns a status.
• Check if pointers are NULL before de-referencing them - it's common to set a pointer that isn't used or has just been initialized to NULL. If while running a program, you de-reference a pointer to NULL (generally address 0), very bad things will happen. If there's an OS, you will segmentation fault, if there's not, something worse will probably happen.
• Test if before you fly it - if you haven't tested every logical path possible your flight program could take, you probably shouldn't fly it. It's easier to solve problems when the computer is on the ground.

More good ideas are elaborated on below:

• Flight Computer "Modes"