Spartan programming

Home

Pages

The Babylonian tower principle

Character count

Generic names

Horizontal complexity

Interface complexity

Miller's law

Number of tokens

Readability

Routine

Variables elimination

Vertical complexity

About

Spartan programming

Spartan programming gathers many techniques discussed in the literature, adding some of its own, into a unique coding style whose main objective is minimal use of various elements of the programming language which may contribute to complexity. This programming style relies on strict self-discipline, avoiding some of the opportunities offered by the underlying language, geared at achieving the programming equivalent of laconic speech.

Spartan programming is not directly concerned with readability, at least not in its subjective and cultural-dependent sense. In fact, spartan programs will bring much misery to anyone preferring long, verbose programs.

In certain ways, spartan programming is a coding style, just like the Linux kernel style guide. But, spartan programming is more than just a technical coding style, in that is has a single underlying, unifying principle - minimalism and simplicity taken to extremes.

History

The coding guidelines began with a dozen or so printed pages, "a little book of style", which the author handed out to computer science students in the Hebrew university of Jerusalem. The term "Spartan Programming" was coined in 1996, when the author gave a tutorial on "Spartan C++" at the TOOLS (Techniques of Object Oriented Languages and Systems) scientific conference, held in Santa Barbara, CA USA. The guidelines were taught under this name in numerous Technion courses since then.

Metrics

Spartan programming strives for simultaneous minimization of all of the following measures of code complexity:

Horizontal complexity, that is, the depth of nesting of control structures, just as the total line length.

Vertical complexity, that is, module length in lines.

Token count

Character count

Parameters, that is the number of parameters to a routine or a generic structure.

Variables

loops, that is the number of iterative instructions and their nesting level.

conditionals, that is the number of if and multiple branch switch statements.

The latter two are related to, but not the same as cycolomatic complexity

Rationale

On the one hand, the Babylonian tower principle states that there is a limit to the number of abstraction levels that a software system may have. On the other hand, the seven plus minus one or two principle sets a limit on the number of subcomponents that may constitute a super component. The spartan programming approach makes it possible to erect slightly higher software towers, by stretching the capabilities of basic modules further. Simple, spartan like modules, make a stronger foundation.

Techniques

The main techniques offered by the discipline are:

Frugal use of Variables

Minimizing the number of variables, by inlining variables which are used only once, grouping related variables in a common data structure, and by using advanced programming constructs such as foreach loops (for (Variable in Collection)) and other chaining constructs in supporting languages

Minimizing the visibility of variables and other identifiers. That is to say, defining these at the smallest possible scope.

In C++ one would thus prefer variables defined in a block to those defined in a function scope; function scoped variables are better than class scoped variables, i. e., fields; and fields are not as desirable as variables defined in the file scope. Further, variables defined in the file scope are better made static so that they are not visible in other files.

Minimizing the accessibility of variables, by preferring greater encapsulation, e. g., private variables, to public variables.

Minimizing the variability of variables, that is striving to make variables final in Java, const in C++, etc., and by using nonnull annotations or restrictions, whenever the development environment or programming language supports it.

Minimizing variables' name length, by applying the generic names technique.

Minimizing variables life time, by preferring ephemeral variables to longer lived ones, and by avoiding, as much as possible, persistent variables (i. e., files and the such).

Thus, in C, one should prefer auto (that is stack) variables to static variables. Heap storage on the other hand, although potentially shorter lived than static data, is considered inferior, since heap management requires extra code.

Minimizing the use of arrays, and replacing these by collections provided by standard and of-the-shelf libraries.

Small interfaces

Minimizing the number of parameters each modules takes.

Minimizing the interaction possible through these parameters, by preferring input parameters to output parameters, output parameters to input-output parameters, input-output parameters to parameters passed by reference, and parameters...