Easy refactoring wins that will increase the readability of your code

1. Extract compound conditionals to methods

Compound conditionals, or pieces of logic comprised of two conditions, are almost always better served as a named method. The biggest benefit of this refactoring is making something that was once implicit, explicit. To copy Ben Orenstein's words, it's more important to write code that tells why it does since all code already says what it does. Let's look at some code that tells us what it does:

// 🛑
flagComment () {
  if (account.age < 10.days.ago && account.karma < 5) {
    ...
  }
}

People new to the codebase will ask another developer what the significance of an account's age and karma are when combined.

"Oh, that's how we know if an account has a higher chance of being spam".

This conversation will continue to happen whenever someone new is brought on. Wouldn't it be great if that question could be skipped entirely? This is achievable by following the extract method refactoring. We can give a name to the abstract idea that our two conditions represent when used together, making the code tell us why it does.

// ✅
accountHasHighSpamRisk () {
  return account.age < 10.days.ago && account.karma < 5
}

flagComment {
  if (accountHasHighSpamRisk) {
    ...
  }
}

The only change is moving the compound conditional to its own method, but the code has become immediately more clear by removing implicit ideas.

It doesn't need to be a compound conditional to obfuscate why the code does. Even conditionals can benefit by being extracted to a named method.

// 🛑
showOnFeaturedPage () {
  if (created_at < 10.days.ago) {
    // do stuff
  }
}

// ✅
showOnFeaturedPage () {
  if (wasRecentlyPublished) {
    // do stuff
  }
}

wasRecentlyPublished () {
  return created_at < 10.days.ago
}

2. Don't mix else-if with returns

This might be the easiest of easy wins. If you're already using return in your conditionals, you can replace if else-if with plain ol' ifs to improve readability.

// 🛑
function doTheThing () {
  if (foo) {
    return true
  } else if (bar) {
    return false
  } else {
    return null
  }
}

// ✅
function doTheThing () {
  if (foo) {
    return true
  }
  if (bar) {
    return false
  }
  return null
}

3. Spell out the entire name of something — no shorthand

Naming things might be the hardest part of writing software. The professor for my compiler design class often used 'a', 'b', and 'c' as variable names when explaining concepts and it's no wonder why I'm now at the polar opposite side of naming conventions.

Is saving three keystrokes more important than easy-to-understand code?

Your code should match how you talk about it. You shouldn't use notif if you actually mean notification. Omitting 7 letters has now forced me to spin my brain one extra cycle to determine what word this truncated variable actually stands for.

An even worse scenario is when both versions exist in unison. Revisiting old code can lead to questions like "Is there a difference between cert and certificate?" Or wondering why your code won't work when you replaced all instances of inc but missed when it was named increment

// 🛑
function getFName () {
  return customer.firstName
}

// ✅
function getFirstName () {
  return customer.firstName
}

That's it!

Those three tips should make your code easier to understand and change. Now go forth and remember these tips the next time you're reviewing a pull request.