Introducing the Treasure Map Design Pattern

A look at a new JavaScript development technique

50 years ago, writing software was much different, and easier. RAM had not been invented yet, so programs could be, at most, a few lines long. There was no need to really think about what you were doing, since you could not do very much.

Fast forward 60 years. It is the year 2014. The year of the JavaScript developer. OUR year. Computer Science has finally earned the “science” portion of its name. As well as the “Computer” portion, as well. Because using computers is now a science.

Any one can USE a computer. But what about writing software? Unlike 80 years ago, we now have a thing called RAM (Randomly Accessed Memory). And in that time software has gotten more complicated to write, and read. So complicated, in fact, that only scienctiest could read the code developers were writing.

Then came design patterns…

What are Design Patterns?

“What are design patterns?” I hear you asking yourself. This is something that I hear daily. It’s hard to explain, but A design pattern is a thing that makes your code easier to read. It could be anything really. But the point is to make it so that other people can easily make changes to your code once you are fired.

The problem with reading code

Here is an example of your typical modern day web 2.1 Java application. It has all the typical hallmarks of a typical application. For instance, there is an AJAX call, an if / else statement, some functions and a jQuery or two.

Now, I could tell you what this does, but you probably couldn’t figure it out on your own, because I haven’t used any design patterns to write this. So how do we make this more readable? Well there are a number of design patterns we could use. A popular one is called the ‘comment’ pattern, which involves adding comments to your code. A JavaScript comment looks like this

// i am a comment

Comments are good for telling why something is happening but not where something is happening. And when you are working a big project (100+ LOC [lots of code]), where is the most important thing to know.

Treasure Map pattern

I designed the treaure map design pattern to tell us now just what our code is doing, but where our code is doing. That’s why it is called “Treasure Map” Because “maps” tell you where things are. And because every day is a gift (which is a synonym for treasure).

The treasure map design pattern extends the comment design pattern by using comments in a very specific way.

First we have the comment which looks like this

//

Then we have indicators.

X — external function call
R — return statement
E — Event branch
L — LOOP

Last, are something I call trails. we use |, -, and + to indicate code trails between different sections of code.

Real world example

Lets apply this to the code in the screen shot above. First we add comments to the right side of our source code

Then we indicators and trails

Now we have a complete and instantaneous understanding of where our program is doing. Thats the Treasure Map in action.

Skeptics need not apply

You might be saying to yourself, “Come on there is no way that is helpful in anyway.” If so, you are a skeptic and I am about to prove you wrong. Let’s say some dumb dumb head comes by and deletes some of your precious code without thinking of the consequences.

Guess what happens. Try to guess. Just take a guess. This is what happens

Look at the part I squrcled in red. Those are incomplete trails, or danglers. Danglers are very easy to spot and instantly tell you if some part of your code has no where to go. Which would be an error.

See how scientific it is?

If you enjoyed this article please recommend or retweet it, PLEASE

Nicholas Ortenzio was raised by wolves