else 예약어를 쓰지 않았는가? - 우아한테크코스 우테코 클린코드 #3

else 예약어를 쓰지 않기 - 우아한테크코스 우테코 클린코드 #3

 

이전글에 이어 우아한테크코스에서 요구하는 클린코드 원칙들을 살펴본다. 

 

---

else 예약어를 쓰지 않기 

 

if/case 구문은 인간의 언어 구조를 그대로 모사하고 있어 직관적으로 이해하기 쉽다. 

 

~ 하면 ~ 이고, 아니면 ~이다 와 같은 문법이다. 

 

하지만 <소트웍스 앤솔러지>에서는 객체지향의 생활 체조 2단계 규칙으로서 else 예약어를 금지하는 것을 제안한다. 

 

아래와 같은 코드가 일반적인 형태의 if/else 구문이다. 

public static void endMe() {
   if (status == DONE) {
      doSomething();
   } else {
      doAnother();
   }
}

 

 

위와 같은 코드에서 else를 제거하는 방법은 무엇이 있을까? 

 

erarly return의 구조를 도입하는 것이다. 

 

public static void endMe() {
   if (status == DONE) {
      return "result from doSomething method";
   } 
   if (status != DONE) {
   	 return "result from doAnother method";
   }
}

 

이와 같은 구조의 장점은 확실히 가독성이 높아진다는 것이다. 

 

if ~ else의 본질적인 특성은 첫번째 조건과 그에 딸려오는 '만족하지 않는 상황의 전제'가 반드시 인지되어야 한다는 점이다. 코드가 복잡해진다면 어떻게 될까? 컴퓨터는 오류를 발생하지 않겠지만 이와 같은 인식의 층위가 두터워질수록 코드를 읽어야 하는 사람은 오류를 범할 가능성이 높아진다. 

 

---

 

우테코 프리코스를 하면서 주어진 과제를 수행하며 이와 같은 규칙을 적용해 리팩토링을 해보았다. 

 

 

else if 구문을 단순히 early return 구조로 바꾸는 것만으로 가독성이 좋아진 것을 확인할 수 있다. 

 

이 외에도 else if 예약어를 쓰지 않고 코드를 짤 수 있는 다양한 방법들이 있을 수 있다. 예를 들어 enum으로 한정값을 설정한 상태에서 throw 하는 형태로 if문 자체를 쓰지 않는 방법도 가능할 것이다. 

 

코드를 리팩토링하는 실력이 늘수록 단순히 메소드를 분기하는 형식으로가 아니라 다양한 방식으로 단순화, 집약화를 이루어낼 수 있지 않을까 생각한다. 

 

 

 

한편, "else 예약어를 쓰지 않는다"는 클린코드 규칙이 반드시 좋기만 한가에 대해서는 고민해볼 필요가 있을 것 같다. 

 

논리 흐름의 특성상 메서드에게 최소 역할을 분담하더라도 그 최소 역할 자체가 로직이 복잡한 경우가 있을 수 있다. 

 

너무 많은 메서드의 분리가 오히려 객체 지향의 본질적인 성격을 훼손한다면 else 예약어를 쓰는 것이 나을 때가 있을 수도 있을 것 같다. 

 

모름지기 규칙이란 목적을 지향하는 과정에 필요한 도구인 법이다. else 예약어 금지 조언 역시 이와 같은 관점에 맞게 적용해야 하지 않을까 하는 생각이 든다.