DEV Community: Michael Kovacevich

Ditching the "else" Statement

Michael Kovacevich — Sat, 16 Oct 2021 20:43:17 +0000

Are "else" statements really necessary? When first learning to program we are taught about "if" statements and "else" statements. If this condition is met do something, else do another thing. It's fundamental to nearly every programming language, but can we ditch the "else" statement?

The Case for Ditching It

Like with most things in programming there will be scenarios where using an "else" statement is more appropriate than avoiding it, but let's assume that we want to ditch it no matter what scenario arises. How would we do that and why would we want to?

The best way to explore this approach is through examples so let's start with a simple one. All of the examples below are written in Typescript:

// With "else"
const areEqual = (value1: string, value2: string) => {
  if (value1 === value2) {
    return true;
  } else {
    return false;
  }
};

// Without "else"
const areEqual = (value1: string, value2: string) => {
  if (value1 === value2) {
    return true;
  }

  return false;
};

This is a common scenario where the "else" statement should be omitted because it is adding more code without adding value. Of course, this entire function is adding code without adding value, since you could just use the "===" operator directly, so let us complicate things a bit more. What if we don't want to "return" from inside our if block?

const getFullName = (
  givenName: string,
  lastName: string,
  preferredName?: string
) => {
  let firstName = "";
  if (preferredName) {
    firstName = preferredName;
  } else {
    firstName = givenName;
  }

  return `${firstName} ${lastName}`;
};

There are several ways to get rid of that "else" statement which also improve the readability of the function. For example, a ternary can be used in these situations:

const getFullName = (
  givenName: string,
  lastName: string,
  preferredName?: string
) => {
  const firstName = preferredName ? preferredName : givenName;
  return `${firstName} ${lastName}`;
};

This has the added benefit of letting us use a "const" instead of a "let", but wait a minute, this is cheating! A ternary is essentially an "if/else" statement with less syntax, so we didn't really ditch the "else" statement!

Let's try again:

const getFullName = (
  givenName: string,
  lastName: string,
  preferredName?: string
) => {
  const firstName = getFirstName(givenName, preferredName);
  return `${fullName} ${lastName}`;
};

const getFirstName = (givenName: string, preferredName?: string) => {
  if (preferredName) {
    return preferredName;
  }

  return givenName;
};

That is much better, but for the minimalists out there you could also write it this way:

const getFullName = (
  givenName: string,
  lastName: string,
  preferredName?: string
) => `${getFirstName(givenName, preferredName)} ${lastName}`;

const getFirstName = (givenName: string, preferredName?: string) =>
  preferredName || givenName;

The real sticklers will note that this could be done in one function and would reduce the lines of code and the number of characters used:

const getFullName = (
  givenName: string,
  lastName: string,
  preferredName?: string
) => `${preferredName || givenName} ${lastName}`;

This is a great little function, but in combining the two functions into one the reusability has gone down. What if we only want to get the first name? We no longer have a dedicated function to do it! Of course in a real code base simply using the "||" operator to pick between the two values would be acceptable and would result in less code:

const fullName = `${preferredName || givenName} ${lastName}`;

However, their is also a readability trade off since having a specific function makes it clear what operation is being executed. This along with the reusability is why the dedicated functions is preferred.

Alright enough talk about minimizing code, let's get back to the "else" conversation. However you choose to implement functions similar to those above, you do not need an "else" statement to accomplish the task. Both examples here show the two main ways to avoid using an "else" statement: "returning early" and "extracting smaller functions".

Returning early is a straight forward concept. The idea is to return your result (including void) as soon as you can, in other words, minimize the amount of code that needs to be executed. If we return early we can omit "else" and "else if" statements as they just become redundant.

Extracting smaller functions should be a familiar technique to most software engineers. In both Functional and Object Oriented Programming this is often referred to as the Single Responsibility Principle, the first of the SOLID Principles. We want our functions, classes, and methods to have a single purpose/responsibility. Many engineers make the mistake of defining a single responsibility with a scope that is far too big, resulting in classes, methods, and functions that are large and have many smaller responsibilities. Every large responsibility is made up of smaller responsibilities, and the more of those we identify and isolate, the closer we are following the Single Responsibility Principle.

Following these two techniques will result in fewer "else" statements without even trying. Sounds like if we write our code with good fundamentals we should never need an "else" statement, so why use them at all?

The Case for Keeping It

The only real case for continuing to use "else" statements is convenience, and this is a pretty strong argument. Whether you are working within a legacy code base or just rushing to make a tight deadline, "else" statements are the last things on your mind. However, I still hardly use "else" statements. Not because I'm consciously thinking about it, but because I usually keep my functions small and single purposed, so the need for "else" statements rarely arises. From time to time an "else" statement or two isn't a big deal, but only when it's convenient.

So how often does this convenience arise? Unfortunately, very often, especially in legacy code bases. Finding an existing code base that is strictly following best practices and conventions is a rarity, and honestly that's a good thing for technological progress. Innovation lies somewhere between idealism and pragmatism, as does the decision to use an "else" statement or not.

Conclusion

End of the day, do what is best for you and your team. Most legacy code bases I've seen have plenty of technical debt beyond the number of unnecessary "else" statements being used. I would however encourage everyone reading this to create a Standards and Conventions document for your team. Depending on the size and experience the team, the document may be very small with just enough detail to let the engineers know what is expected of them. For medium to large teams a document like this is essential and should be constantly referenced, maintained, and updated. The standards and conventions you add over time will show the progress that your team has made towards having a higher quality code base. Maybe you'll even include "No Else Statements" as a standard, but probably not.

Reducing Technical Debt - Where to Start?

Michael Kovacevich — Mon, 06 Jul 2020 15:07:48 +0000

When working within a legacy system, there can be quite a bit of pre-existing technical debt. As feature requests come rolling in with an ever-growing pressure to deliver quickly, the technical debt only grows. So how do you stop the bleeding? Where do you start?

Getting Your Priorities Straight

As Software Engineers, we notice different issues than the business and customers. We see the spaghetti code; we sniff out the code smells; we look at the 16,000 line files with a sense of dread and terror. The customers don't see these things and will only notice the side effects that negatively impact their experience. Likewise, the business is concerned with pleasing the customers and providing them value.

It's easy for us to rattle off the downsides of accumulating technical debt: how it is not maintainable and how it can lead to high developer turnover; however, the business likely is not going to listen to these cries. They want new features, that's what sells software, and that's what keeps the lights on. So instead of pointing fingers and expressing our anguish, let's shift the priorities.

What's Important to The Business?

While we may want to start dealing with the most atrocious examples of technical debt in our systems, that doesn't always align with what's most important to the business and our customers, so the first thing we need to do is figure out what is important to them. What are the critical features, the ones that result in customers leaving if they don't work, the ones that mean the difference between signing a new client and losing them to a competitor? Once we know what these critical features are we have our set of priorities.

What's Important to Us?

Now that we have an idea of the business's priorities how do we prioritize from our perspective? We can take a look at the business-identified critical features and determine which ones require the most improvement: which features have the most reported issues or most frequently reported issues?; which take us the longest to debug?; give us the most grief?; lead to the most burnout? Answering these questions will help us order our priorities.

Preparing to Take Action

At this point, we've asked a lot of questions to both the business and ourselves. We should have a list of features that the business deems most important to our customers, and each of these features should be ranked by the amount of improvement needed. What process you employ to obtain and rank these priorities is up to you, but once you have completed this exercise, you're almost ready to start taking action.

Before that can begin, it's a good idea to prepare a backlog of tasks. These tasks should be small in scope and should drive you towards the improved code base you desire. Some of these tasks will need to be finished in a particular order, so be sure to keep track of that when you create the tasks in whatever system you are using to manage your projects (Jira, GitHub, etc). It may be helpful to refer to these tasks as "Technical Debt Tasks" or something along those lines.

Working Technical Debt Tasks Into Your Sprints

When planning your sprints, try to include at least one technical debt task (preferably one per each developer on the team), fitting the tasks in with the feature work and bug fixes that are chosen for the sprint. This will help ensure that you are always making progress towards your goal of reducing technical debt in your system.

There are alternatives to this approach. Some teams choose to have special coding sessions to work on technical debt. Doing this can indicate that your team doesn't value the reduction of technical debt as high as it values building features and eliminating bugs. Also, these sessions are sometimes scheduled after normal working hours - requiring developers to put in extra time to participate, giving off the impression that the accrual of technical debt is the fault of the developers. It most certainly is not. Technical debt can grow as a result of any participant in the software development process or could even be the result of a flaw in the process being used.

Another alternative to working technical debt tasks into your sprints is to not address it at all. Instead, some teams may choose to replace existing services with new ones. While this may seem tempting, especially when the code is exceptionally messy, it requires developers to split their time between building new services and maintaining the old ones. If this works out for your team, by all means, do what works for you, but it can be a major time waster if it is not executed properly.

Choosing to work on technical debt tasks as part of each sprint continuously adds value at the end of each iteration. You avoid putting it off until you have time for a special refactor session that may never happen, and you won't find yourself waiting for the big payoff that your new services will deliver (assuming you ever finish them). Take it one sprint at a time and your code will keep getting better and better, baby steps.

All of us manage our software projects differently: maybe you use sprints, maybe you don't. If your team doesn't use sprints, the advice above still applies. The point is to work on technical debt tasks as part of each cycle. Treat them as if they are just as important as feature work and bug fixes because they are.

Conclusion

Addressing technical debt is an ongoing effort so these phases of identifying debt, preparing tasks, and working them into your sprints will be repeated over and over again. It's an iterative process. When you first set out on your mission to reduce technical debt ask a lot of questions. Ask the business, ask your customers, ask yourselves. The more insight you have into what parts of your software matter the most, the better off you will be. Once you have collected your data, start prepping your tasks, and work them into each sprint. Lather, rinse, repeat, and your system will start becoming more maintainable and reliable.