the zen of source code formatting

 

Source code—assuming for a moment that you didn’t already know this—is a collection of (often English) words and symbols for humans which usually is turned into something more meaningful for a computer to understand when the program is running. Each computer language has its own rules about how you order the words and symbols but most allow for a fair amount of leeway with respect to whitespace, the “rests within the melody”, if-you-will.

“most [computer languages] allow for a fair amount of leeway with respect to whitespace, the rests within the melody…”

“Source code formatting is the task of using that whitespace to maximize… something.”

Source code formatting is the task of using that whitespace to maximize… something. This of course means different things to different people. For some, they believe that source code formatting can be done only one way. To format code using any other method, in their mind, would be the equivalent of breaking some sort of law.

Others believe that your text editor knows best and should be the authoritarian on the matter. There’s usually a feature to “format document” which they believe always gets this right.

As someone who’s been coding now for almost forty years, I’d like to share what I’ve learned and to permission you to completely ignore those first two camps who would say that you must do it their way.

The Virus

In my humble opinion, nearly all of the source code formatting as seen in the world’s collection of code suffers from poor readability. And this is so because of the attitudes surrounding the topic as well as the self-imposed “leaders” and big players who believe their way is better, demanding adherence to their own opinions.

In many software development firms, this is a hot topic for debate. Coders feel strongly about how all this plays out. Outspoken individuals like Douglas Crockford (author of jslint) have even developed tools to enforce their own (wrong) ideas about how code must be formatted.

As large corporations like Google publish more in the open source area, they bring with them this kind of Draconian mindset. If you bring in their code, you’re very likely also bringing in format-enforcing restrictions which come along for the ride.

“If we think of jslint as a virus that self-propagates, then cloning a Google-published project has now infected your project.”

I have personally been held hostage for days trying to make the jslint build tool happy when I’ve been forced to use it. It’s one of the worst anti-patterns I’ve seen in this industry, to be honest.

An Innovative & Meaningful Method of Formatting Your Source Code

For me, I choose to maximize whitespace instead so that I may understand the code instantly. The more I understand the code, the less likely it is that I will later introduce a bug into this code. The faster I can speed-read the code, the more productive and happier I’ll be.

“Code Complete” by Steve McConnell

The genesis of this new method comes in part from my having read this excellent book at least twenty years ago. At the time, this was ground-breaking in its revelations of coding statistics with respect to bugs and the impact of good source code formatting to minimize their presence in code.

My method goes beyond the author’s original suggestions and is the work of a couple decades in the making.

A Practical Example

Below, I show a pair of examples. It is the same code, just differently formatted. The code language is JavaScript and is written for NodeJS, more specifically. The other examples below also are written in JavaScript.

Before (classic jslint-like formatting)

Screen Shot 2018-11-29 at 12.20.13 PM
Figure 1

After (new, suggested method)

Screen Shot 2018-11-29 at 12.22.26 PM
Figure 2

Hopefully you will see the appeal to the second method. The spacing in Fig. 2 allows us to quickly see that this section includes the creation of several variables by pulling them in from separate files and modules. Additionally, they are alphabetized to make it easier to spot accidental double-inclusions.

Given the column-like behavior and the symmetry of those “require” functions, it’s now much easier to scan down the list. It’s now a pleasure to read.

Before (classic jslint-like formatting)

Screen Shot 2018-11-29 at 12.30.22 PM
Figure 3

After (new, suggested method)

Screen Shot 2018-11-29 at 12.17.01 PM
Figure 4

Here, by tightening up the first/third activities to become single-line events in Fig. 4, it’s easier to then see that we have what appears to be a sandwich-like construction:

  1. fs.closeSync() something
  2. create a variable
  3. fs.closeSync() with that variable

The second activity now has some pretty radical source code formatting. But it follows the column rule introduced from before:  columns make assignments easier to scan.

1) The Column Rule

To sum this up: use consistent whitespace to create columns out of assignments (storing a value into a variable). This applies to multi-line assignments as well as to assignments which take more than one line to accomplish.

Create columns: “…use consistent whitespace to create columns out of assignments…”

2) Squash for Readability

If it is possible to remove vertical space so that an entire function may be reviewed in one screenful in your editor, then consider doing so. Good candidates for this treatment are the open/close pairs of file functions seen in Fig. 4. The pairing makes sense to most coders so it’s a welcome form of abbreviation.

Squash: “If it is possible to remove vertical space so that an entire function may be reviewed in one screenful in your editor, then consider doing so.”

3) Comment the Breadcrumb Trail

When there are several levels of braces in one group at the end of something, clearly comment each with judiciously-provided whitespace so that they line up as a column as seen in Fig. 5.

Screen Shot 2018-11-29 at 12.45.00 PM
Figure 5

Breadcrumbs: “When there are several levels of braces in one group at the end of something, clearly comment each with judiciously-provided whitespace so that they line up as a column…”

4) Semicolons for Readability

Use line-ending punctuation to tell one type of scope/block from another. In Fig. 5 above, fs.readdir() and fs.unlink() as function calls are each terminated with a semicolon after the ending brace. Here, I’m omitting the terminal semicolons for both the sections in the if blocks and the for loop at their ending braces.

Semicolons: “Use line-ending punctuation to tell one type of scope/block from another.”

I’m sure this one will have its critics. I would argue that the introduction of chained functions and the concept of “Promises” have created some rather interesting “dogpiles” of code at times which are too difficult to follow without this strategy.

Applicability to Other Languages

The suggestions indicated also apply to other languages. One notable caution, though, goes out to Python-related code which is fairly picky about beginning indentation style. The beginning of each line of Python marks logical blocks of codes as you might see in a matching pair of braces in JavaScript. It’s therefore critical to first make Python happy in this regard before attempting to then adhere to these suggestions. The continuation line technique seen in Fig. 4 above would not work in Python for this reason.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s