개발할 때 흔히 있는 경우로 메소드에 초기 조건을 확인한 후 일정 조건을 만족할 때에만 로직을 실행하는 경우가 있다.
이런 초기조건을 확인하는 형태는 크게 두 가지가 있는데, 각각 장단점이 있다. 다음의 예1)과 예2)를 보자.
예1)
public int doSomthing(int value1, String value2) {
if (value1 > 0) {
if ("OK".equals(value2)) {
// do something
return SUCCESS;
} else {
return ERROR_2;
}
} else {
return ERROR_1;
}
}
예2)
public int doSomething(int value1, String value2) {
if (0 == value1) {
return ERROR_1;
}
if (!"OK".equals(value2)) {
return ERROR_2;
}
// do something
return SUCCESS;
}
예1)은 참인 조건을 중첩해서 쌓고 하단에 else로 각각의 에러를 정의하는 방식이다.
장점
- 메소드 시작부분과 로직 내용이 가깝다.
보통 코드를 읽으며 메소드에 오게되면 메소드 이름을 통하게 되고 당연히 제목이 있는 맨 윗줄부터 보게 되는데 이 때 로직을 바로 확인할 수 있어 유용하다.
단점
- 에러 처리를 확인하기 어렵다.
이는 Exception으로 변경하여 보완할 수 있다.
- indent가 너무 깊다.
심한 경우에는 가로 스크롤이 필요할 수도 있다.
- {}가 너무 많고 로직이 길어지는 경우 각 묶음(?)이 길어진다.
어떤 에러가 어떤 조건에 걸리는 건지 확인이 힘들다.
예2)는 에러 조건을 확인해서 에러인 경우 먼저 처리하고 모든 초기 조건 검사를 통과했을 때, 로직을 실행하는 방식이다.
장점
- indent가 얕다.
- 에러 처리 확인이 쉽다.
단점
- 코드가 아래로 길어진다.
아무래도 예1)보다는 길어질 수 밖에 없다.
- 로직을 확인하려면 메소드에서 아래로 내려가야 한다.
나는 개인적으로 예2)의 방식을 선호한다.
다른 사람은 어떻게 생각할지 모르겠지만 난 예1)이 정신없어 보인다.
게다가 예1)에서 실수로 닫는 괄호가 꼬이게 되면 (닫는 괄호 하나가 지워지거나 하면) 굉장히 헷갈리는 일이 생긴다.
그리고, 모든 조건이 영향을 미치는 코드는 가능한한 짧을수록 좋다고 생각하기 때문에 예2)를 더 좋아한다.