CleanCode::Code::Namespaces (NM1)

Namespaces allow you to conceptually place resources in different containers, greatly reducing the possibility of collisions. Some languages (Java, Perl) support namespaces, some (JavaScript, C) do not. In Java, all functions and variables are defined within classes -- there are no global ones. So the only global objects to deal with are classes. Classes, then, may either be defined within a specific package (namespace) or, if no package is specified, within the default package, called "the default package."

Let's back up to talk about general program structure. A trivial program typically is contained in one file, perhaps using some library routines, and doesn't need to care about namespaces. In Java, the default package is assumed. In Perl, the main package is assumed. In JavaScript, there are no packages, so we could argue that there is also a default package. Moving to a program of any complexity, however, you will create more than one file. There will still be one file that is the main program. That main program invokes routines from both system libraries, and from your other files. For clean code, then, all of your other files should also be libraries. That is, each of your files, except the main, should be in an appropriate namespace/package, and should be included in your main program just like system library files are. The table shows the directives used to connect libraries to your main program.

Associating Libraries in different languages
Language	Directive
Java	`import`
Perl	`use` or `require`
C	`include`
JavaScript	--

In Java, it is a challenge not to use packages. Java tries very hard to require clean coding techniques. Perl, however, is a lot more forgiving. There is no enforcement as in Java, but there is at least capability. In RP1, we talked about namespace collisions in JavaScript; JavaScript does not have any notion of packages, but... with a little effort, you can introduce it yourself.

The following JavaScript technique is most handy when writing object-oriented code, though it is still usable in non-OOP, just less nifty. In Java one references a method in a specific package via the dot notation, e.g. System.out.println(). Similarly in Perl, one would use e.g. HTML::Template->output() In JavaScript, we're constrained by what we can do with a single legal identifier name. So we use the underscore (_), as in the following example:

EXAMPLEJavaScript

Filename: File/Parse.js

function File_Parse(filename) {
	. . .
	this.parseInt = File_Parse_parseInt;
	this.parseReal = File_Parse_parseReal;
}

function File_Parse_parseInt(n) {
	. . .
}

function File_Parse_parseReal(n) {
	. . .
}

Filename: main.js

var parser = new File_Parse(name);
var i = parser.parseInt(n1);
var r = parser.parseReal(n2);

To the outside world--that is, to anyone outside this file who wishes to use a Parse object in our pseudo-package File--all of the methods for this object have simple names--parseInt, parseReal, etc. Only the constructor has a compound name.

This prevents any possibility of namespace collisions in JavaScript. Plus, it has the advantage that one can see where the Parse object comes from--the File package, in this example. Furthermore, one has the advantage of apparent method overloading. That is, one could have a Fruit_Apple object and a Fruit_Orange object (which clearly should not be compared :-), each of which has a puree method. Internally, Apple.js and Orange.js in the Fruit directory would each have their own definitions, Fruit_Apple_puree and Fruit_Orange_puree, respectively.

Style note: OneTwo. one_two. The world can be divided into two kinds of people: those who use capitals for multi-word distinction, and those who use underscores. The careful observer will note that this JavaScript technique requires both, used in specific ways. So this will probably make nobody happy... See also NM2 for further discussion of naming conventions.