Work with me here. This is not about being cheap.

Before I enrolled in The Iron Yard’s front-end engineering boot camp, I was a freelance editor and proofreader. One pet peeve was the belief that the $20 word was better than the $2 word. Sure. By all means, increase your vocabulary, but when someone uses “endeavor” instead of “try”, my wanker-meter goes off. Loudly. Even better are those who write “endeavor to try”. Schaaahp. Leave “endeavor” for when your audience is fohncee and wearing wings made from peacock tail feathers. If you have a regular audience, “try” is good. There’s a time for Boccaccio and a time for concise instructions.

In order to write better code — to go from advanced beginner to intermediate — I’ve started reading The Art of Readable Code (copyright 2012 Dustin Boswell and Trevor Foucher, 978-0-596-80229-5, O’Reilly Books). It’s an easy read (buy it!). They don’t bog us down with those $20 words to show off all that they know. Their goal is to teach, not entertain or transport us to Edwardian England. I could read this in a day, but I won’t. I’d get nothing from it. I’ll take a small bite, savor the flavors, compliment the chef, and say “Good gad, Godfrey! This is delicious!” Or maybe I’ll just write about what I learned. I don’t know. I like saying “Good gad, Godfrey!”

The $2 code is easier to read. Good. Now what? Do it. Bugger! Everything is rough at the start of learning. The master potter once made hideous lumpy ashtrays. I acknowledge that, but that doesn’t mean that I’m okay staying there and populating my house and code with some fugly ashtrays.

My first aha: Better names for loop iterators.

I had been using i, j, and k to name my indices. On the surface, those names look good enough. They work. We know what we mean. Index i. If there are nested loops, then move to j and k. It makes perfect sense. It does until we stumble and need to debug. Nesting does my head in. Nested if-else and loops are the wire hangers of code for me. Or the toddlers jacked up on Skittles and Kool-Aid. How would I know what is wrong in my code if I have

if(course[i].class[k] == student[j]){//do amazing things}

It might look like it makes sense to me. I might spend time figuring out the code inside the block and not realize that it’s my indices that are wrong.

What if I had named my indices course_i, class_i, and student_i? Or, to make it shorter: crs_i, cls_i, stu_i? How would this help? You tell me:

if(course[course_i].class[student_i] == student[class_i]){//do amazing things}

or

if(course[crs_i].class[cls_i] == student[stu_i]){//do amazing things}

The first line tells me that my problem is in my if-condition. My indices do not match up. The second line has indices that match up, so right away, I would think that my problem is in my code block.

I will never again. Even for just i in a small practice code on Codepen. If I reuse it, I don’t want to have to change my name for the index.  The benefit of clarity outweighs any increase in code size. It’s like the Oxford Comma. If I use it all of the time, I don’t have to switch when I need it to be clear:

I will give Dustin Boswell, Trevor Foucher, and Cletus O’Reilly $1000.

Clearly, I’m going to divide 1000 by three and send them on their merry way, each with $333.33 (I’ll keep the penny).

I will give Dustin Boswell, Trevor Foucher and Cletus O’Reilly $1000.

Do I give Dustin $500 and make Trevor and Cletus split the other half ($250 each)? Or do they each get a third? They don’t know. I have not made that clear.

If I do it all of the time, I don’t have to pause and think about future issues. Bud nipped. The Art of Readable Code has been a valuable read so far. Not a lot of steamy sex, but I hear that’ll change in the next printing.