I’ve long held that good code is like poetry (and I’m far from the only one). Everything should have a purpose, and if you ever repeat yourself, there should be a good reason. With various high-level coding languages, you can enable or even automate incredibly complex tasks with relatively little effort, and it’s done by building on the foundations of lower-level machine languages, mid-level operating systems.

And since all that work has already been done, programming for a high-level language should feel a little like playing golf. I have all of these set tools at my disposal, now how do I get to the goal with the lowest number of moves?

One of the things I’ve seen consistently in new programmers, and something I observed in myself when I first started dabbling, is a misunderstanding of exactly how useful arrays can be, or even how to use them effectively.

If you clicked on this by mistake, or are just curious, you might not be familiar with the term array. An array is a collection of variable data. It can hold just about anything you can think to put in it, strings like:

"Hello World."

Numbers like:

42

Functions like:

function(){ return 'The Thing';}

Or objects, and even other arrays. Most textbooks and classes will also tell you that you can iterate through all of these elements to analyze or manipulate the data.

But, despite a very accurate and broad definition, that doesn’t begin to touch on the core concept behind why grouping these elements is important, and what exactly they can enable. Let’s start more simply and get larger as we go.

I’m going to be using JavaScript syntax for all of the following examples, but many of the concepts I discuss can be carried over into any language that uses an array or array-like construct. JavaScript is an especially good language to first understand arrays because it only supports numerically indexed arrays. While data within the array can be dynamic, you can be sure that if what you are accessing is actually an array, the keys are all the same format and are sequential. While this limits their functionality, it also makes it harder for you to get lost.

So let’s start off easy. Let’s say you have an array of strings:

var strings = [
	'Take', 
	'Me', 
	'Home', 
	'Where', 
	'The',
	'Grass', 
	'Is', 
	'Green', 
	'And', 
	'The', 
	'Girls', 
	'Are', 
	'Pretty'
];

If we were to loop through that array, say with:

for(var i = 0; i < strings.length; i++) {
	return strings[i];
}

We would get some lyrics from Paradise City in order, but if we were to do something like:

for(var i = 0; i < strings.length; i++){
	return strings[Math.floor(Math.random() * strings.length)];
}

Then we would end up with something completely different, making something possibly unique with a preset grouping of data.

For example, before I worked at Armor, I spent a substantial portion of my free time teaching myself JavaScript by building a full game around this concept. Polished or practical it was not, but it does use random number generators to choose from a relatively large number of possibilities to create dynamic text output for player feedback. To see it in action, you can visit the game here: https://goblinpuncher.itch.io/gpx

The game has combat, dynamic histories for encountered enemies, random weapons, quests, and a leveling system all built around arrays and random access to them.

But as a concept, random access only has limited use on an everyday basis outside of small subsets of programming like encryption work.

But that’s not all you can do with them. For a brief stint, also before Armor, I got a job building a Point Of Sale system for a local business based on a JavaScript only prototype I built for them. The system leveraged the Local Storage object to save its “Database,” but those ended up being nothing but nested arrays structured not unlike a more traditional database. What this meant was that, just like a database driven application, I could access a large amount of data about an inventory item or purchase by knowing the id of the record in question, or the more impressive application, if I don’t know the id, the records could be quickly searched through, since they all resided in memory, and that functionality can be as simple as a type comparison, or as complex as running a substring or search on the data.

I would never recommend using JavaScript arrays as a replacement for a database in a production application, but in a demonstration like that one, it meant I could show off my vision for the software without installing anything on the client’s system, and since the data lives in the client’s memory, it can’t directly affect the server. This means it can demonstrate the full functionality, without the risk of giving full database access to anonymous users, who could break something.

But that’s still not everything you can do. We recently implemented stronger password security in our business, and part of that came down to a password rating system. A few years ago, I probably would have hardcoded my tests and just run them one at a time by calling them the traditional way, but if you think about it, wouldn’t it be better to build an array of functions and run them sequencially, allowing the rules to be dynamic and easily changed over time?

var tests = [
	function length(score){
		return score;
	},
	function characters(score){
		return score;
	},
	function capitols(score){
		return score;
	},
	function weak(score){
		return score;
	},
	function common(score){
		return score;
	}
];

Then I can just loop through them like so:

var score = 100;
for(var i = 0; i < tests.length; i++){
	score = tests[i](score);
}
if(score < 25){
	return 'Your Password is Weak.';
}

And you don’t have to name your functions if you’re comfortable using anonymous ones. With this approach, a semi-random number generator, and some conditional logic, you can put together a basic AI relatively quickly.

Here at Armor, we use arrays for just about everything. If you see a piece of code without a loop of some kind over something we’ve pulled from the database, you’re either looking at a static page or a relatively minor piece of our framework. We use arrays for passing back search data, for analyzing visitor statistics, for importing and converting old database schemas, building out navigation trees to search them for bad links, file browsing, and so much more.

And I think that’s the disconnect. On its own, a grouping of data is relatively useless, but by linking that grouping to an access or manipulation concept, like looping, random, or indexed access, it opens a lot of fundamental doors that aren’t inherently obvious when the concept behind an array is explained. And that seems to be where most people I’m interviewing get caught up. Arrays and Loops as concepts are not important on their own, they are foundational. They are tools that allow us to build much more complex functionality on top of them.