Show Menu

Applying Nasa Coding Standards to Javascript Cheat Sheet by

programming     javascript     standards     nasa


JPL have been developing software for most of unmanned missions in the field of deep space and other planets exploa­ration. High level of autmat­ization and long duration of missions led to superior demands to software quality. As a result of JPL amazing experience a set of code guidelines was developed and published recently. Since demands to web-driven software constantly increase and more critical tasks are entrusted to JavaSc­ript, lets apply NASA coding guidelines to JavaScript / HTML applic­ations for higher perfor­mance, reliab­ility and the better world.

1, Function Length

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 and one line per declar­ati­on. Typically, this means no more than about 60 lines of code per function.

This fits perfectly for JavaSc­ript. Decomposed code is better to unders­tand, verify and maintain.

2. Restri­cting All Code

Restrict all code to very simple control flow constructs – do not use goto statem­ents, setjmp or longjmp constr­ucts, and direct or indirect recurs­ion.

Rule from the C world makes wonder. We definitely will not use goto or setjmp in JS, but what is wrong with recursion? Why NASA guidelines prescribe to avoid simple technique we were studying as early as in school? The reason for that is static code analyzers NASA use to reduce the chance for error. Recursions make code less predic­table for them. JavaScript tools do not have such a precept so what we can take out of this rule?
Use constructs which are justified by comple­xity. If you want to write reliable code – drop to write tricky code and write predic­table. Define coding standard and follow it;
Use code analyzers to reduce chance for defect: JSHint­/JS­Lin­t/G­oogle Closure Tools;
Keep codebase by monitoring metrics: Plato;
Analyze types with Flow/G­oogle Closure Tools.

3. Do not use dynamic memory allocation after ...

Do not use dynamic memory allocation after initia­liz­ati­on.

At first glance JavaScript manage memory itself and garbage collection cleaning memory from time to time solving the rest of problems for us. But it is not absolutely correct. Memory leaks often, spoiled JavaScript developers do not have a culture of managing memory, garbage collector decrease perfor­mance when run and it is hard to tame. Actually we can get three recomm­end­ations from this rule. Two of them are nice to follow in any project and last one fits for perfor­mance and reliab­ility critical software.
Manage your variables with respect. Regularize variables declar­ation by putting them in the top of scope in order to increase visibility of their usage;
Watch for memory leaks, clean listeners and variables when not needed anymore. Classic article;
Switch JavaScript to static memory mode and have predic­table garbage collection behaviour (means no accident perfor­mance regression and no sawtooth pattern) by using objects pool.

4. All loops must have a fixed upper-­bound.

As JPL explains this makes static analysis more effective and helps to avoid infinite loops. If limit is exceeded function returns error and this takes system out of failure state. For sure, this is quite valuable for software with 20 years uptime! Checks for limit exceeds are curried out by assert­ions. You may find more details on assertions in fifth rule. If you accept assertions practice use limits for loops as well, you will like it.

5.The assertion density

The assertion density of the code should average to a minimum of two assertions per functi­on.

It is good to put few words here on what assertion is. The simplest parallel for them are unit tests which executes in run time.
1 if (!c_as­ser­t(a­ltitude > MAX_PO­SSI­BLE­_AL­TITUDE) == true) {
2 return ERROR;
3The rule literally says:

“Stati­stics for industrial coding efforts indicate that unit tests often find at least one defect per 10 to 100 lines of code written. The odds of interc­epting defects increase with assertion density.”

Great, does this mean that we can treat rule as: “Write unit tests!“? Not exactly. Speciality of assertions is that they execute in run time and closest practice for JavaScript land is a combin­ation of unit tests and run time checks for program state conformity with generating errors and errors handling.
Than higher is tests density than less defects you get. Minimal amount of tests is 2 per function;
Watch for anomalies in system state in run time. Generate and handle errors in case of failures.

6. Data objects must be declared ...

Data objects must be declared at the smallest possible level of scope.

This rule have simple intention behind – to keep data in private scope and avoid unauth­orized access. Sounds generic, smart and easy to follow.

7. The return value of non-void functions

The return value of non-void functions must be checked by each calling function, and the validity of parameters must be checked inside each functi­on.

Authors of guideline assure that this one is the most violated. And this is easy to believe because in it`s strictest form it means that even built-in functions should be verified. On my opinion it makes sense to verify results of third party libraries being returned to app code and function incoming parameters should be verified for existence and type accord­ance.

8. The use of the prepro­cessor

The use of the pre-pr­ocessor must be limited to the inclusion of header files and simple macro defini­tio­ns. The C pre-pr­ocessor is a powerful obfusc­ation tool that can destroy code clarity and befuddle many text based checkers.

Using pre-pr­oce­ssors should be limited in any language. They are not needed since we have standa­rdized, clean and reliable syntax for putting commands into engine, it makes even less sense taking into account that JavaScript is constantly evolving. Reliable and fast JavaScript should be written in JavaSc­ript. Nice research on determ­ining the cost of JS transp­ilation

9.The use of pointers

The use of pointers should be restri­cted. Specif­ically, no more than one level of derefe­rencing is allowed. Function pointers are not permitted.
This is the rule JavaScript developer can not get anything from.

10. All code must be compiled

All code must be compiled, from the first day of develo­pment, with all compiler warnings enabled at the compiler’s most pedantic setting. All code must compile with these setting without any warnings.

We all know it… Do not hoard warnings, do not postpone fixes, keep code clean and perfec­tionist inside you alive.

Download the Applying Nasa Coding Standards to Javascript Cheat Sheet

2 Pages

PDF (recommended)

Alternative Downloads

Share This Cheat Sheet!



No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          CoffeeScript language Cheat Sheet

          More Cheat Sheets by Davidpol

          Police Scanner Codes 14 – 19 Cheat Sheet