NASA’s 10 rules for developing safety-critical code

Published: January 8th, 2015 by 

NASA’s been writing mission-critical software for space exploration for decades, and now the organization is turning those guidelines into a coding standard for the software development industry.

The NASA Jet Propulsion Laboratory’s (JPL) Laboratory for Reliable Software recently published a set of code guidelines, “The Power of Ten—Rules for Developing Safety Critical Code.”

The paper’s author, JPL lead scientist Gerard J. Holzmann, explained that the mass of existing coding guidelines is inconsistent and full of arbitrary rules, rarely allowing for now-essential tasks such as tool-based compliance checks. Existing guidelines, he said, inundate coders with vague rules, causing code quality of even the most critical applications to suffer.

“Most serious software development projects use coding guidelines,” Holzmann wrote. “These guidelines are meant to state what the ground rules are for the software to be written: how it should be structured and which language features should and should not be used. Curiously, there is little consensus on what a good coding standard is.”

Holzmann laid out 10 strict rules for developing software with code safety in mind. The rules were specifically written with the C language in mind (a language NASA recommended for safety-critical code due to its long history and extensive tool support), though the rules can be generalized for coding in any programming language.

1: Restrict all code to very simple control flow constructs. Do not use GOTO statements, setjmp or longjmp constructs, or direct or indirect recursion.

2: All loops must have a fixed upper bound. It must be trivially possible for a checking tool to statically prove that a preset upper bound on the number of iterations of a loop cannot be exceeded. If the loop-bound cannot be proven statically, the rule is considered violated.

3: Do not use dynamic memory allocation after initialization.

4: 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 declaration.) Typically, this means no more than about 60 lines of code per function.

5: The assertion density of the code should average a minimum of two assertions per function. Assertions must always be side effect-free and should be defined as Boolean tests.

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

7: Each calling function must check non-void function return values, and the validity of parameters must be checked inside each function.

8: Preprocessor use must be limited to the inclusion of header files and simple macro definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed.

9: The use of pointers should be restricted. Specifically, no more than one level of dereferencing is allowed. Pointer dereference operations may not be hidden in macro definitions or inside typedef declarations. Function pointers are not permitted.

10: All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting. All code must compile with these setting without any warnings. All code must be checked daily with at least one—but preferably more than one—state-of-the-art static source code analyzer, and should pass the analyses with zero warnings.

Holzmann included detailed rationales for each of these rules in the paper, but the general gist is that together, the rules guarantee a clear and transparent control flow structure to make it easier to build, test and analyze code along broadly accepted but all-around disjointed standards. JPL has developed automated software for deep space missions such as the Mars Curiosity rover and the Voyager probe, and the laboratory is already using the rules on an experimental basis to write mission-critical software.

Holzmann believed that complying with NASA’s rules, strict as they might be, can lessen the burden on developers and lead to better code clarity, analyzability and safety.

“If the rules seem Draconian at first, bear in mind that they are meant to make it possible to check code where very literally your life may depend on its correctness: code that is used to control the airplane that you fly on, the nuclear power plant a few miles from where you live, or the spacecraft that carries astronauts into orbit,” he wrote.

“The rules act like the seat belt in your car: Initially they are perhaps a little uncomfortable, but after a while their use becomes second-nature, and not using them becomes unimaginable.”

Applying NASA’s coding standards to JavaScript
NASA JPL’s rules for developing safety-critical code are broad enough to generalize to writing code in any programming language, but one developer has already connected the dots to the most popular Web development language out there: JavaScript.
.... .... ....

Read more:

Simple JavaScript OOP for C++, Java and C# Developers

by , 30 Dec 2014 BSD


Most developers are familiar with object-oriented programming and design in languages like Java, C++ and C#. JavaScript, however, does not provide any obvious means to support this kind of object-oriented development. The result is that structured code becomes very hard to write for developers new to the world of JavaScript.
If you have written a few programs in JavaScript and wondered if it's possible to add more structure to your programs using object-oriented strategies, this tip is for you. In this post, we will look at the use of a small JavaScript utility that allows us to structure our JavaScript programs in the form of "classes" and objects.


Traditionally, object-oriented programming relies on creating classes and creating object instances from classes. This approach to OOP was pioneered by a language known as Simula and eventually became the basis of object-oriented programming in popular languages such as C++ and Java.
Object-oriented programming in JavaScript, however, comes from a different OOP paradigm known as prototype-based programming. It was first introduced by the language Self with the aim of solving some problems in class-based programming. This style of programming has no concept of classes, and being very different from the class-based style we're usually familiar with, it requires a learning curve.
The utility presented below, however, provides a way to mimic class-based OOP in JavaScript.

Creating Objects

First, let's look at the basic structure for putting together a class:

    var ClassName = Object.$extend({
        initialize: function () {
            //this is the mandatory constructor. All class members should be initialized here.
            this.publicMember = 'Some value';
            this._privateMember = 'Another value';
        publicFunction: function () {
            //Code for a public function.

        _privateFunction: function () {
            //Code for a private function

    var anObject = new ClassName();
New "classes" are created by extending the base Object type. $extend is a function that we have created for this purpose. initialize is, by convention, called automatically every time we create a new object and is therefore the constructor. All private and public members should be declared in the initialize function.
It is important to note that the "private" members shown above are not really private at all. Unfortunately, JavaScript doesn't offer a means to easily mark members as private and for that reason we prefix them with an underscore to indicate them as such. anObject._privateFunction() would have worked without any issues, but users of our class should be aware of our convention and not attempt to use it directly as it is prefixed with an underscore.

A Detailed Example

The following is an example of an "Animal" class built using our utility. We will use this class for our examples on inheritance:

    //This is a basic "Animal" class. $extend is a method
    //provided by the utility. To build a new class, we 
    //"inherit" from the base Object type

    var Animal = Object.$extend({

        //"initialize" is the constructor function for objects
        //of type Animal.

        initialize: function (gender) {
            //Notice that we declare members _gender and _food in
            //the constructor. Declaring member variables in the
            //constructor is important.

            this._gender = gender;
            this._foods = [];

        //Simple getter and setter functions for the _gender

        getGender: function () { return this._gender; },
        setGender: function (gender) { this._gender = gender; },

        //This function adds an item to the _food array

        addFood: function (food) {

        //self-explanatory -- removes an item from the
        //_foods array

        removeFood: function (food) {
            for (var i = this._foods.length; i--;) {
                if (this._foods[i] === food) {
                    this._foods.splice(i, 1);

        //Boolean function to check if this animal will eat a particular type of food.

        willEat: function (food) {
            for (var i = this._foods.length; i--;) {
                if (this._foods[i] === food)
                    return true;
            return false;
There we have it! A class for creating Animal objects. The following code sample creates Animal objects and shows how they are used:

    var lion = new Animal('male');
    var parrot = new Animal('female');


    lion.willEat('fruits'); //false
    lion.willEat('meat'); //true
    parrot.willEat('fruits'); //true

    lion._gender // 'male'
    //Unfortunately, JavaScript doesn't easily support "private" properties 
    //in objects. The _gender property we created is publicly readable and
    //writable. By convention, we prefix "private" properties and functions
    //with and underscore to indicate them as such.


Just like we created our base Animal class by extending the type Object, we can create child-classes of the Animal class by extending it. The following snippet creates a "Human" type that inherits from Animal.

    //Extend the Animal type to create the Human type
    var Human = Animal.$extend({
        //Constructor for the Human type
        initialize: function (name, gender) {
            //Notice the call to the parent constructor below. uber behaves just like
            //super and base in Java and C#. This line will call the parent's
            //initialize function and pass gender to it.
            this.uber('initialize', gender);

            this._name = name;

            //These functions were defined in the Animal type
        goVegan: function () {
        //Returns something like "Mr. Crockford"
        nameWithTitle: function () {
            return this._getTitlePrefix() + this._name;
        //This function is publicly accessible, but we prefix it with an underscore
        //to mark it as private/protected
        _getTitlePrefix: function () {
            if (this.getGender() === 'male') return 'Mr. ';
            else return 'Ms. ';

The new Human class can be used as follows:

    var jack = new Human('Jack', 'male');
    var jill = new Human('Jill', 'female');
    jill.nameWithTitle() + ' eats meat? ' + jill.willEat('meat'); // Ms. Jill eats meat? false
    jack.nameWithTitle() + ' eats meat? ' + jack.willEat('meat'); // Mr. Jack eats meat? true

Notice the use of the "uber" function in the constructor. Similar to "base" and "super" in C# and Java, it can be used to call the base class's functions. The next example will show another use of the uber function.
It is important to note that the base class's constructor is automatically called without any arguments (new Animal()) while defining the Human subtype. We called it the second time using "uber" to make sure it initializes the properties to proper values. It is important to make sure that the initialize function doesn't throw any error if called without any arguments.

More Inheritance Examples

The following code shows more examples of using OOP and inheritance using our handy utility:
    var Cat = Animal.$extend({
        initialize: function (gender) {
            this.uber('initialize', gender);
        speak: function () {
            return 'purrr';

    var DomesticCat = Cat.$extend({
        initialize: function (gender) {
            this.uber('initialize', gender);
        speak: function () {
            return this.uber('speak') + ', meow!';

    var WildCat = Cat.$extend({
        initialize: function (gender) {
            this.uber('initialize', gender);
        speak: function () {
            return this.uber('speak') + ', growl, snarl!';

    var kitty = new DomesticCat('female');
    var tiger = new WildCat('male');
    'Domestic cat eats orijen? ' + kitty.willEat('orijen'); // Domestic cat eats orijen? true
    'What does the domestic cat say? ' + kitty.speak(); // What does the domestic cat say? purrr, meow!
    'What does the wild cat say? ' + tiger.speak(); // What does the wild cat say? purr, growl, snarl!


To use this library, download the code and include inherit-min.js or inherit.js in your code.


A copy of the code is also available on GitHub under the BSD license: OOP in JavaScript: Inherit-js on GitHub.


This article, along with any associated source code and files, is licensed under The BSD License

[JavaSpecialits] - Memory Usage of Maps

Memory Usage of Maps

by Dr. Heinz M. Kabutz
In this newsletter we measure the memory requirements of various types of hash maps available in Java. Maps usually need to be threadsafe, but non-blocking is not always the most important requirement.

Welcome to the 193rd issue of The Java(tm) Specialists' Newsletter, sent from the amazing Island of Crete. A few weeks ago my Greek teacher introduced me to "aoristos", the simple past. This is great, because now I can bore my Greek friends with wild tales of life in Africa when I was a child. "Ipia me tous elefantes" - I drank with the elephants. The beauty of being from Africa is that Europeans will believe anything you say. "Ahh, so you had a lion as a pet? I knew it!" If you know a bit of Greek, try this aoristos flash card test. My name is on top at the moment, but I'm sure I will easily be dethroned :-)

In my previous newsletter, I challenged you to explain why the anonymous class sets the this$0 field before calling super(). Kai Windmoeller was the first to send me a partial reason and Wouter Coekaerts was the first with a perfect explanation. Both Kai and Wouter subsequently sent me other clever ideas that I would like to incorporate in future newsletters. [And the explanation is ....... you'll have to figure that out yourself :-) A hint though, if you compile the class with -source 1.3 and -target 1.3, it does not do that. See what issues that can cause and you will see why we need this.]

In-house courses if these dates or locations do not suit you. Note that the course in Crete may also be attended remotely via webinar.

Memory Usage of Maps

My newsletter is strongly connected to my courses. When I research Java for my newsletter, ideas emerge on how to improve my advanced Java courses. Questions asked during the courses often stimulate ideas for new research topics. It is a delicate ecosystem. They cannot exist without each other.
A few months ago, during one of my masters courses, one of the programmers mentioned that they had noticed a memory bottleneck with the ConcurrentHashMap. They were creating about 100000 maps and wanted them to be threadsafe. The natural choice seemed to be the ConcurrentHashMap, since it, well, is supposed to work with concurrent access.

The ConcurrentHashMap splits the bucket table into a number of segments, thus reducing the probability that you would have contention when modifying the map. It is quite a clever design and scales nicely to about 50 cores. Above 50 cores, you would be better off using Cliff Click's Highly Scalable Libraries. Since my friends did not need high scalability, the ConcurrentHashMap seemed fine.

Whilst doing a memory profile, JVisualVM showed that the top culprit was the ConcurrentHashMap.Segment class. The default number of segments per ConcurrentHashMap is 16. The HashEntry tables within the segments would probably be tiny, but each Segment is a ReentrantLock. Each ReentrantLock contains a Sync, in this case a NonFairSync, which is a subclass of Sync and then AbstractQueuedSynchronizer. Each of these contains a queue of nodes that maintain state of what is happening with your threads. It is used when fairness is determined. This queue and the nodes use a lot of memory.

Many years ago, I wrote a newsletter that demonstrated a simple memory test bench. It would construct an object, then release it again with System.gc() and measure the difference. Here is a slightly updated version of the MemoryTestBench. It still does virtually the same, with the only enhancement that I sleep a bit after each System.gc() call:

public class MemoryTestBench {
  public long calculateMemoryUsage(ObjectFactory factory) {
    Object handle = factory.makeObject();
    long memory = usedMemory();
    handle = null;
    memory = usedMemory();
    handle = factory.makeObject();
    return usedMemory() - memory;

  private long usedMemory() {
    return Runtime.getRuntime().totalMemory() -

  private void lotsOfGC() {
    for (int i = 0; i < 20; i++) {
      try {
      } catch (InterruptedException e) {

  public void showMemoryUsage(ObjectFactory factory) {
    long mem = calculateMemoryUsage(factory);
        factory.getClass().getSimpleName() + " produced " +
            factory.makeObject().getClass().getSimpleName() +
            " which took " + mem + " bytes");
I created an ObjectFactory interface and some basic classes to test that it still worked correctly:

public interface ObjectFactory {
  Object makeObject();

public class BasicObjectFactory implements ObjectFactory {
  public Object makeObject() {
    return new Object();

public class IntegerObjectFactory implements ObjectFactory {
  public Object makeObject() {
    return new Integer(333);

public class LongObjectFactory implements ObjectFactory {
  public Object makeObject() {
    return new Long(333L);
I tried this out with Java 1.6.0_24 on my Mac OS X 10.6.8 and with a self-built Java 1.7.0 based on the OpenJDK. I also tried 32 vs. 64 bit, server vs. client on the 32 bit and the flag -XX:+UseCompressedOops on the Server Hotspot Compiler. The -server and -client made the least difference, so I only include the -server results. Also, the results for Java 1.7.0 were similar enough to 1.6.0_24 that I will only show the 1.6 data:

Java Version 1.6.0_24 with -server
32/64bit         64   64   32
CompressedOops   No  Yes  N/A
Object           24   24    8
Long             24   24   16
Integer          24   24   16
It looks as if the -XX:+UseCompressedOops flag has no effect on these objects. You will only see the difference with more complex objects that have pointers to others. This flag can also speed up your application substantially if you are using a 64 bit machine.

Here are some factories for creating various hash maps. The first is not threadsafe, the other two are:

public class HashMapFactory implements ObjectFactory {
  public Object makeObject() {
    return new HashMap();

public class SynchronizedHashMapFactory implements ObjectFactory {
  public Object makeObject() {
    return Collections.synchronizedMap(new HashMap());

public class HashtableFactory implements ObjectFactory {
  public Object makeObject() {
    return new Hashtable();
We see that even basic hash tables differ greatly in size between various implementations. If memory space is a major issue, like it was for my friends, then the Java 1.0 Hashtable class might work best. Hashtable is fully synchronized, which means that it will cause contention when accessed from more than one core at a time. It also uses integer division to locate the correct bucket, which is slower than the bit masking approach used since Java 1.4. However, if memory is your bottleneck, then Hashtable might be a good solution. Here are the memory sizes:

32/64bit          64   64   32
CompressedOops    No   Yes  N/A
HashMap           216  128  120
SynchronizedMap   272  160  152
Hashtable         176  112   96
The ConcurrentHashMap allows us to construct it with a concurrency level, which is used to calculate the number of segments that the map will contain. The actual number of segments is a power of 2 greater or equal to the concurrency level. Thus if we construct a map with concurrency level of 200, it will create 256 segments. As mentioned above, every segment is subclassed from ReentrantLock. Thus we will show the sizes for ReentrantLock, and ConcurrentHashMaps with sizes 16 (the default), 2 and 256:

public class ReentrantLockFactory implements ObjectFactory {
  public Object makeObject() {
    return new ReentrantLock();

public class ConcurrentHashMapFactory implements ObjectFactory {
  public Object makeObject() {
    return new ConcurrentHashMap();

public class SmallConcurrentHashMapFactory implements ObjectFactory {
  public Object makeObject() {
    return new ConcurrentHashMap(16, .75f, 2);

public class BigConcurrentHashMapFactory implements ObjectFactory {
  public Object makeObject() {
    return new ConcurrentHashMap(16, .75f, 256);
Based on these results, we can see why the ConcurrentHashMap uses so much memory, even when it is empty.

32/64bit                    64      64      32
CompressedOops              No     Yes     N/A
ReentrantLock               72      56      40
ConcurrentHashMap         2272    1664    1272
SmallConcurrentHashMap     480     312     272
BigConcurrentHashMap     34912   25664   19512
Another option is Cliff Click's Highly Scalable Libraries.

import org.cliffc.high_scale_lib.*;

public class HighlyScalableTable implements ObjectFactory {
  public Object makeObject() {
    return new NonBlockingHashMap();
Click's empty NonBlockingHashMap uses a lot less memory than the ConcurrentHashMap.

32/64bit                  64     64      32
CompressedOops            No    Yes     N/A
ConcurrentHashMap       2272   1664    1272
NonBlockingHashMap 1312 936 872
Let's see what happens when we put some elements into the map, by writing an ObjectFactory that fills the map with objects. By adding autoboxed Integers from the integer cache and constant Strings, we can measure the hash map overhead, instead of the objects contained inside the map.

public class FullMapObjectFactory implements ObjectFactory {
  private final ObjectFactory factory;

  protected FullMapObjectFactory(ObjectFactory factory) {
    this.factory = factory;

  public Object makeObject() {
    return fill((Map) factory.makeObject());

  protected Map fill(Map map) {
    for (int i = -128; i < 128; i++) {
      map.put(i, "dummy");
    return map;
With this particular data set, the NonBlockingHashMap uses the least amount of memory, but I have seen other data sets where the Hashtable uses the least. You would have to try it out in your particular situation to find the best possible map for your needs. Also remember that the NonBlockingHashMap scales to hundreds of cores, whereas the Hashtable would have contention with two.

32/64bit                    64      64      32
CompressedOops              No     Yes     N/A
ConcurrentHashMap        30024   21088   16872
SmallConcurrentHashMap   16736   10488    8400
BigConcurrentHashMap     48144   34040   26416
Hashtable                15440    9792    7728
NonBlockingHashMap       10912    6696    6632
As in all performance issues, you need to measure and not guess. Please only change your code if you have measured and verified that this is indeed your bottleneck.

Kind regards from sunny Crete

P.S. You might have seen disturbing images of Greek rioting. Fortunately this is far away from where we live on the Island of Crete. The despair is quite real though.