How to make your code reads like a poem? Beautiful boolean variables

The code should read like well-written prose. That’s why you should be careful about booleans.

This article is part of a clean code in-depth course called Clean Code: Skyrocket Your Programming Career in 7 Days you can check it out. It’s currently available at an 87% off discount.

Since you are often using them in if statements you have a chance to make the code reads really really well OR make the code look really crappy and hard to read. Let’s see an example:

if(person.hunger < 6.8 && person.money >= getClosestOpenResurant(person.location).dinnerPrice && day() < 6){
   // make an order
}

You are seeing this code for the first time, do you understand it? Or do you need some time thinking about it? I’m sure that you will figure it out eventually, but you need time. Now let’s extract the booleans and give them names. Let’s see if this will make the code read well:

boolean personIsHungry = person.hunger < 6.8;
boolean personCanAffortDinner = person.money >= getClosestOpenResurant(person.location).dinnerPrice;
boolean isWeekDay = day() < 6;
if(personIsHungry && personCanAffortDinner && isWeekDay) {
   // make an order
}

Now imagine seeing this code for the first time. Let’s read the if statement. If person is hungry and person can afford dinner and it’s weekday — then make an order. I think that’s way better, don’t you think? But I still don’t like it. See, the first two booleans are working with the Person object. This logic can be encapsulated inside the object. Also, we can create an object for the weekday logic:

class Person {
   // fields here
	
   pubic boolean isHungry() {
      return hunger < 6.8
  }
	
   public boolean canAffortDinner() {
      return person.money >= ResturantUtils.getClosestOpenResurant(person.location).dinnerPrice
   }
}
class TimeOperations {
   public static boolean isWeekday() {
      return day() < 6;
   }
}
if(person.isHungry && person.canAffortDinner && TimeOperations.isWeekDay) {
   // make an order
}

Now we have a Person class with the boolean methods in it. And we have a TimeOperations class that has an isWeekday method. Now let’s see the if statement. It’s one line of readable code. If you see that for the first time you won’t have a problem understanding what’s going on. This is because we hide the details inside named blocks of code. You should do this not only with booleans, but with all the code you are writing.

I see a lot of people writing code like this:

public void deleteUser(int id) {
   if (loggedUser != null) {
      if(loggedUser.sessionExpired()) {
         // log erorr and throw
      }
      if(loggedUser.isNotAdmin()) {
         // log erorr and throw
      }
      userRepository.delete(id);
   } else {
      // throw
   }
}

With lots of nesting. Nesting code is hard to read. Try your best to avoid it. Do you see where we delete the user? This is our main logic. The rest is the details. See how the main method logic it’s wrapped around checks and details. If I need to understand this logic I will need to go through all the other code surrounding it and then I will go to the line I want to see. And we might not care about the other code. In this case, we can just make the validations separately from the business logic. To do that we just need to flip the first if and then copy the other checks after it as so:

public void deleteUser(int id) {
   if (loggedUser == null) {
      // throw
   }
   if(loggedUser.sessionExpired()) {
       // log erorr and throw
   }
   if(loggedUser.isNotAdmin()) {
      // log erorr and throw
   }
   userRepository.delete(id);	
}

Of course, this is works for this example. You might have a different case. Just try to separate the checks and details from the main logic.

See how we unwrapped the business logic. Much better. I want you to to see two things:

1. First — See the differences between the two methods and think about them.
2. Second — Think of a way to make the deleteUser method cleaner. What can we do to make the business logic be the center of view.

The thing we can do is… that’s right folks, extract the validations in the separate method as so:

public void deleteUser(int id) {
   validatePermissions();
   userRepository.delete(id);
}
private void validatePermissions() {
   if (loggedUser == null) {
      // throw
   }
   if(loggedUser.sessionExpired()) {
      // log erorr and throw
   }
   if(loggedUser.isNotAdmin()) {
      // log erorr and throw
   }
}

See the deleteUser method now, it’s much better that way. We have one line for the validations and one line for the actual method’s logic. If we want to see the validations, we go inside the validatePermissions method. Again, we don’t need to pollute the methods with details. See the difference between the methods. You can clearly see which is better.

Before You Go — Our Amazing Clean Code Course currently available at an 87% off discount

If you loved this article, you will love our course:

• 46 lectures
• 3+ hours of content
• Working on a real-life project that will test your knowledge
• 27 downloadable resources
• 30-Day Money-Back Guarantee

You can sign up for the course here — Clean Code: Skyrocket Your Programming Career in 7 Days