읽기 쉽게 흐름제어 만들기
더스틴 보즈웰, 트레버 파우커
느낌표 ! (인상 깊은 문장 | 문맥)
이번 챕터에서는 책의 예제에서 크게 벗어나지 않는다고 생각하지만 필자가 예제를 각색하여 적는 부분이 꽤 있다. 한편으로는 예제를 그대로 쓰는 것이 독자에게 더 유익하지 않을까 싶기는 하지만 가능하면 각색하는 것이 필자가 더 고민함으로 얻는 것이 있고 독자도 더 특색있는 글을 읽게 된다고 생각한다. 물론 각색이 더 훌륭하다고 생각하지는 않는다. 위험성이 도사리지만 걸어가보려한다. —
조건문에서 인수의 순서
다음 두 코드 중에서 어떤 코드가 더 읽기 쉬운지 생각해보라.
if (member.count() >= 5)
혹은
if (5 <= member.count()
…
while (loaded < total)
혹은
while (total > loaded)
대부분의 프로그래머는 첫 번째 코드가 더 읽기 쉽다고 느낄 것이다. (생략) 우리가 발견한 유용한 규칙은 다음과 같다.
왼쪽 | 오른쪽 |
---|---|
값이 더 유동적인 ‘질문을 받는’ 표현 | 더 고정적인 값으로, 비교대상으로 사용되는 표현 |
이러한 가이드라인은 영어 어순은 일치한다. “당신이 적어도 1년에 10만 불을 번다면” 혹은 “당신이 적어도 18세라면” 이라고 말하는 것은 자연스럽다. 하지만 “만약 18년이 당신의 나이보다 작거나 같다면” 이라고 말하는 것은 부자연스럽다.
p.104 - 105
데이터가 변경되는 대상을 왼쪽에 적는 것이 더욱 가독성이 높다고 저자는 논리적으로 설명하고있다. 영어 어순으로 예를 드니까 확연하게 차이가 와닿는다. 개발하면서 이 원칙으로 생각을 하면서 개발했지만 이제 논리와 근거까지 추가된 것 같다. chai 의 assert.equal 의 인터페이스는 아래와 같다. 실제 값이 왼쪽에 기대 값 즉 변하지 않는 값이 오른쪽에 온다. 이처럼 변하는 값이 왼쪽에 오는 것은 흔하게 볼 수 있다.
equal<T>(actual: T, expected: T, message?: string): void;
if/else 블록의 순서
if(a == b) { } else { }
다음과 같이 순서를 바꿀 수 있다.
if(a != b) { } else { }
부정이 아닌 긍정을 다루어라.
…
if (!req.params.reverse) { ... } else { list.reverse() }
보다는
if (req.params.reverse) { list.reverse() } else { ... }
…
다음은 부정해야 더 단순하고 흥미로우면서 동시에 위험해지는 경우다.
if(!jwtToken) { // 401 반환 } else { }
p106-108
결국 조건이란 논리인데 부정 또한 하나의 논리이기 때문에 논리를 최소한으로 사용해야 오해를 방지할 수 있다고 생각한다. 단순하고 직관적이여야한다는 것은 한 눈에 보기 좋아야한다는 것을 의미하기도 한다.
함수 중간에서 반환하기
어떤 프로그래머는 한 함수에서 반환하는 곳이 여러 곳이면 안 된다고 생각한다. 이는 말이 되지 않는다. 함수 중간에서 반환하는 것은 완전히 허용되어야 한다. 이는 종종 바람직할 때도 있다.
function login(id, pw) { const userById = findOne({ id: id}); if (!userById) { // 아이디 없는 경우 처리 return; } const userByPw = findOne({ id: id, pw: pw}); if (!userByPw) { // 비밀번호 틀린 경우 처리 return; } // 로그인 성공 처리 }
p.112
예외 처리를 앞에서 미리미리 return 하면 중첩이 줄어든다는 매우 큰 장점이 있다. 중첩이 될수록 가독성이 떨어진다고 생각하기 때문에 필자의 경우 함수 중간에서 반환하기를 매우 애용한다.
Chapter 7 느낌
Chapter 7 에서는 소소하다고 볼 수 있지만 소소한 차이에도 큰 차이가 나는 것을 느끼게 해준다.