Hi, this is Wayne again with a topic “Skill builder: How To Code Like NASA”.
Space, the final frontier since 1985, the national aeronautics and space administration, otherwise known as nasa, has committed itself to the exploration of space, pushing the boundaries of existing technology into the future and behind it all is billions of lines of code responsible for the lives of hundreds Of astronauts and billions of dollars worth of equipment, the code being written by nasa’s jet propulsion laboratory adheres to a set of strict standards. These standards have been used to power the likes of the juno spacecraft, nasa’s, deep space network. The curiosity rover and you know if you want our own personal projects too hi, i’m allison – i make useless but entertaining robot videos on my own youtube channel linked down below and today i’m going to talk about how we can apply nasa’s official coding standards to our Own personal projects, because, while the stuff we build might not always make it to space, i mean one can only dream right. Writing cleaner and more robust code is never a bad idea.
So nasa’s jet propulsion laboratory for reliable software has released a set of 10 guidelines for writing safety critical code. While these rules were originally meant for code written in c, we can repurpose them into general guidelines for the code that powers our own personal projects like python. For the raspberry pi, so we’ve picked through nasa’s rules to find some of those applicable guidelines that you can apply to your own projects and while a lot of these fall in line with already popular best coding practices, they’re a good reminder of some of the core Concepts that we should always fall back on, two of nasa’s rules can be combined for our first tip, and they are no function, should be longer than what can be printed on a single sheet of paper and restrict our code to very simple control flow constructs for Us we can interpret this as the idea of keeping things simple, be intentional, with what you write and do your best to keep things concise practically. This could mean keeping your functions as small and targeted as possible, while it’s definitely tempting, especially when working with microcontrollers, to throw all your code into one big heap just for the sake of getting it working, it can actually cause a lot of trouble down the line In things like readability, for other builders or people, you share your code with reusability when you need to adapt your functions to other uses and finally, predictability, because it’s a lot easier to predict the outcome of a function or class that serves one single purpose. Our next guideline comes from rule number five. The assertion density of the code should average to a minimum of two assertions per function. Practically this means you should probably write some unit tests, small automated pieces of code intended to test components or units of your system.
Now i know unit tests suck to write, they’re, boring and honestly, if you’ve done your job right, they never actually alert you of any issues, but no matter how tedious it can be testing your code before deploying it can save you a lot of time in the Long run because it can tell you when where and hopefully why something in your code has failed when working with microcontrollers, for example, you should aim to have some sort of abstraction layer between your hardware interface and your application logic, so that you can mock and replace Real-Life conditions with a test framework, our last tip – comes from rule number, six compile with all possible warnings active all warnings should then be addressed before the release of the software. I think a lot of us myself included, tend to ignore a lot of the warnings we get just for the sake of getting something working, but, from my experience, the warnings i ignore always tend to get me back later, when some other part of my code is Broken – and i realize it’s that thing that my compiler has been yelling at me about for the last 20 minutes now, not every project we work on will have compiled code. But if you’re working with interpreted languages, the principle stays the same, make sure you’re paying attention to the warnings that you’re receiving and you can do the bulk of receiving and interpreting warnings with linters which are likely available for whatever language you’re working with. So that’s it.
For our tips on how you can write your code to nasa standards, let us know what you think in the comments section. We’Ll also have some more details about nasa standards, as well as a link to my own youtube channel down below. Finally, a big thank you to make for inviting me to be on their channel if you like this type of content, make sure to subscribe to them and we’ll see you in the next one. You .
