Coding Tips: Maintainable Code

KarlBoghossian.com Maintainable Code

In this post I will cover some basic tips into a couple of things I’ve seen other developers do in the past. I won’t go into details, but I hope that’ll help you stay alerted and avoid writing code that smells.

Hardcoded Primitives

Avoid injecting a specific number or string directly in a function.

function getGroceriesFromDatabase() {
  if (this.store.type == “DRIVE_THRU”) {
    // do bla...
  }

  if (this.store.employeeCount > 100) {
    // do bla...
  }
}

Instead define a constant that could be referenced in multiple places, which will make your code more maintainable, and eliminate bugs that could arise by updating a part of the code without updating other relevant parts.

const STORETYPE = {
  DRIVETHRU: “DRIVE_THRU”,
  WAREHOUSE: “WAREHOUSE”
}

const STORESIZETHRESHOLD = {
  MIDSIZE: 100
}

function getGroceriesFromDatabase() {
  if (this.store.type == STORETYPE.DRIVETHRU) {
    // do bla...
  }

  if (this.store.employeeCount > STORESIZETHRESHOLD.MIDSIZE) {
    // do bla...
  }
}

Duplicated Code

Avoid at all costs copy-n-pasting a function into some other class/file as it happens to not be directly accessible from your current code.

I’ve seen folks that would copy and entire function of 10+ lines of code and duplicate it in other files just because it’s “easier”.

Think about that method for a second, I’m sure you’ll find ways to maybe pull that into a Utils class or something, just don’t duplicate the code. Sometimes you can add a couple of parameters to generalize it a bit more and it’ll end up being flexible enough to be re-used across your codebase.

Identify Patterns

As you’re coding, it’s a good practice to train your brain to look for patterns, where you see yourself repeating several lines of code (1+ or so).

function displayStoresList () {
  for (const store in this.stores) {
    console.log(store.name + “ - “ + store.address)
  }
}

function showStoreHours (store) {
  console.log(store.name + “ - “ + store.address + “ - “ + store.hours)
}

Notice how the part that has store.name + “ - “ + store.address seems to be something I’d like to show whenever a store related piece of information needs to displayed.

But in the snippet above, I was repeating it. Imagine you want to change that separator from “ - “ to ” | “. It will be hard to maintain that logic.

// helper method that can be easily maintained and re-used.
function storeNameDisplayedRepresentation (store) {
  return store.name + “ - “ + store.address
}

function displayStoresList () {
  for (const store in this.stores) {
    console.log(storeNameDisplayedRepresentation(store))
  }
}

function showStoreHours (store) {
  console.log(storeNameDisplayedRepresentation(store) + “ - “ + store.hours)
}

Use your judgement, but often times that repeating block is a good candidate to get pulled into a helper class/file, that can be invoked anywhere else in your codebase.

Nested Conditions

When writing your if statements, always lookout for unexpected code paths.

const playerA = {
  name: “Karl”,
  inventory: {
    bodyArmor: “Steel-X1”
  }
}

const playerB = {
  name: “John”
}

function hasBodyArmor (player) {
  // 1. check for inventory
  if (player.inventory) {
    // 2. check for body armor
    if (player.inventory.bodyArmor) {
      return true
    }
  } else {
    return false
  }
}

In the snippet above, we have a function that returns whether a player has body armor. First it checks if player.inventory exists, then if not, it will return false.

If you notice, I have 2 nested if statements, that I thought I had coded defensively by checking for inventory then bodyArmor to make sure my program doesn’t crash, but in fact, the logic is off!

It says if I have inventory, then check for bodyArmor, then return true. In the case that I don’t have inventory, then we’ll return false which is ok. But what if I have inventory but no bodyArmor, I won’t be returning anything, which will yield to an undefined behavior.

Now of course some languages might interpret that “non-return” situation differently, and I could have written the method differently. But the point I’m trying to make is that when you nest if statements, run through them in your head and often times you might see that in some cases, the resulting code paths will be ambiguous.

I hope this post provided any value to you, I used it as a starting point and I’ll be adding similar smaller tips that help you keep your code a bit cleaner and maintainable 🧼

Please do check out the other posts that are part of this Coding Tips series 🍻

0