Slumming around in other people’s code

Image Credit: catsoneverything.com

It’s human to judge, but I’ve found other developers make a part time job out of judging. The main thing I take notice of is how I judge a code base the first time I look at it.

When you’re new to this field, you think you have endless time and skill to improve every code base you get your hands on, nevermind that it’s over 10,000 lines long. Because you’re that good and everyone will love you for improving it.

Having crashed and burned a couple times with this plan, I’ve learned to eat some humble pie and work with whatever code is in front of me, even if the original author is gone. Surprisingly, I’ve learned a lot about myself, other developers, and code quality.

First, in the real world, you learn budgets and time matter. You will do well to grok a code base and refactor it, keeping in mind that nothing is perfect and you can improve/comment it as you go along.

Your fresh eyes are more useful than you think

Your first look over the code base serves a huge importance because you get to see first-hand the pain points that future, helpless developers will. So you have the opportunity to clean up or at least comment the most glaring ones, but do it while there is yet time because the code will become familiar after a few weeks, to the point that confusing things are no longer confusing since you’ve been working around them for so long.

After a few weeks though, I’ve found that the code almost becomes as familiar as though I’ve written it myself. Is this weird? Probably, but that’s why I’m behind the computer and not the counter.

Sit Down, Be Humble

No matter the code base, I can see an earlier version of me in it or a future version of me that I aspire to. We’ve all had to start somewhere. I must always have empathy for others, lest I be the one judged too. FYI, that’s a rough paraphrase of something Jesus said. I don’t think the writer is supposed to explain their own literary devices along the way…

You don’t always know the circumstances in which the original code was written, like whether there was not enough oversight (or too much), or whether the resources and time were scoped well (probably not). After I’ve been in a few of these scenarios myself, I’ve come to appreciate any code base that shows signs of thoughtfulness and coherence because that’s no small feat under pressure.

You may think I’m exaggerating, but I am not. Development is hard and there’s a lot to keep in mind, such as architecture, speed, security, error handling, etc. Under too much pressure, developers often forget the basics and don’t spend 5 minutes to think a rough outline in their head. I’ve come to respect developers who still do this when you realize the pressures they were under. You will too because you are now in their shoes— sucker.

You see your own bad practices smack you in the face

What always tickles me is when I see a bad practice I routinely engage in in someone else’s code. At first, my reaction is negative, then I realize I used that construction probably no less than an hour ago. So I feel what other developers feel when they look at my code.

It may not be some official “bad practice” penned in all the computer science text books since 1995. But you can see a practice that’s more confusing than it needs to be and takes only a short while to make less confusing. You may not realize it is confusing until you see it in someone else’s code, where much of it isn’t familiar to begin with. The practice just adds a little extra speed bump to wrapping your caffeine-addled brain around it.

I have a friend who always asks for examples when I speak in abstractions for more than 30 minutes, so I’ll provide one about this.

You can argue around camel or snake case or bracket placement till your Mountain Dew turns blue, but that doesn’t matter much when you’re doing actual work. The things that start to bother you are things that slow you down and should work when they don’t

The latest one I’ve come across falls under the “don’t repeat yourself” (DRY) rule. It has to do with variables.

Say you have a variable that holds a true or false value. First off, good move to put it in a variable since you plan on using it more than once, tip of the ol’ hat to you. Well, keep using that variable if you need to check for a true of false value. Don’t run another check for the variable condition over and over.

<?php
/* How nice of the programmer person to put a widely used variable at the top so I know it's there, instead of casting it randomly somewhere in the file. */
$sort_by_last_name = false; 
if(isset($_GET['sortlastname'])) {
$sort_by_last_name = true;
}
[...bunch of code doing stuff here...]
/* programmer person probably came back the next day and writes:  */
if(isset($_GET['sortlastname']) { 
$sql->query("SELECT * FROM peeps ORDER BY lastname DESC");
} else {
$sql->query("SELECT * FROM peeps");
}

No, you set that nice variable to already check for that $_GET variable so use it. That way, if I need to change it down the rode, I don’t have to search all over for wherever that check occurs.

What helps avoid this is good variable names. PHPstorm will autocomplete variable names, so if you name it well, you’ll be reminded you already have a variable set for your check.

I’m tired of writing, so I’ll end this post here, without much proofreading. Thanks for reading.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.