Early Return
사람의 뇌는 한번에 한가지만 처리할수 있다.
멀티 태스킹을 잘한다는것이 여러 업무를 번갈아 가면서 처리할때 다른 업무를 처리할 준비를 할 수 있는 능력이 좋다는것을 의미한다.
코드를 작성할때 도입을 한다면
public class ifelse {
void elseif() {
int score = 70;
if (score >= 100) {
System.out.println("A");
} else if (score >= 80) {
System.out.println("B");
} else if (score >= 50) {
System.out.println("C");
} else {
System.out.println("F");
}
}
}
라는 코드가 있을때
점수에 따라 등급이 결정되고 결과값이 C라는것도 알겠지만 이 코드를 해석할때 내가 입력한 점수가 70점이고
이점수에대한 등급을 확인하려고 나는 3단계에 걸쳐서 비교를 해봐야하는것이다.
이것을 빠른 리턴을 통해 수정을 해준다면
public class ifelse {
void elseif() {
int score = 70;
if (score >= 100) {
System.out.println("A");
return;
}
if (score >= 80) {
System.out.println("B");
return;
}
if (score >= 50) {
System.out.println("C");
return;
}
System.out.println("F");
}
}
처럼 수정이 가능하게 된다 해석을 할때 좀더 간단하게 할수 있게 되는것이다.
이처럼 Early Return을 사용하여 else if의 무분별한 사용을 막게되어 좀더 이해하기 쉬운 코드를 작성할수 있게 된다.
사용할 변수는 가깝게 선언하자
void test(){
String returnMessage = "hello";
//코드 30줄
System.out.print("resultMessage : "+returnMessage);
}
해당 코드와 같이 선언을 한 후에 한창 다른코드를 작성하고 마지막에 이렇게 가져다 쓴다면
마지막에 메세지를 보낼때 이게 무슨 메세지 인지 생각해내는 과정이 추가가 된다.
중첩 반복문, 중첩 조건문 줄이기
흔히 코드를 작성할때 이중 for문같은 반복문을 쓰게 될것이다.
하지만 내가 작성했더라 할지라도 코드를 볼때 내 머릿속에선 첫번째 for문이 어떻게 돌아가고
그 다음에 두번째 for문이 어떻게 돌아가고 이 두개가 전부 돌아가면 제일 안쪽에 있는 로직이 어떻게 실행 된다는
텍스트로 적기에도 매우 긴 내용이 된다.
이런 일을 방지하기 위해
적절한 추상화라는 것을 거쳐서 한 메서드 안에 한가지의 일만 하게 하는것처럼
for문 안에있는 이중 for문과 로직을 별개로 분리하여 코드를 작성해주면 이해하기 쉽게된다.
// 수정전
for (int i=0; i<10; i++) {
for (int j=0; j<10; j++) {
if (i > 5 && j < 5) {
System.out.println("true");
}else{
System.out.println("false");
}
}
}
// 수정후
for (int i=0; i<10; i++) {
twoFor(i);
}
private twoFor(int i){
for (int j=0; j<10; j++) {
if (i > 5 && j < 5) {
System.out.println("true");
return;
}
System.out.println("false");
}
}
공백 라인을 대하는 자세
공백 라인은 쉽게 말하여 문단을 나눈다고 생각할수 있다.
사람마다 차이는 있겠지만 서로 다른 의미와 주제를 가진 글을 이어서 작성하지 않고 나누는것처럼
공백 라인을 주어 의미가 다른 코드들을 분리하여 보기 쉽게 만드는 것이다.
부정어를 대하는 자세
뒤에 있는 연산자를 내가 먼저 이해를 하고 이걸 반대로 생각하기 때문에
오히려 뇌속 연산을 한번 더 해야해서 효율이 떨어지고 복잡해진다.
! 이런 부정 연산자의 가독성 또한 낮기 때문에
내가 이 부정문을 쓰지 않아도 되는 상황인지 체크하고 써야한다면 다른 단어가 존재하는지 고민해보고
부정어구로 메서드명을 구성하여 작성하는것이 좀더 가독성이 좋아진다.
해피 케이스와 예외 처리
예외 발생 가능성을 낮추자
해피 케이스대로만 진행이되면 더할나위 없지만 프로그램이란 절대 그럴수 없다고 생각하기에 항상 예외에 대한걸 생각해야한다, 많은 검증을 통해 예외 발생 가능성을 낮추어야한다
어떤 값의 검증이 필요한 부분은 주로 외부 세계와의 접점이다
검증이 필요한 경우는 사용자의 입력, 객체 생성자, 외부서버의 요청 등이 있
의도한 예외와 예상하지 못한 예외를 구분하자
사용자에게 보여줄 예외와, 개발자가 보고 처리해야할 예외를 구분해야한다.
항상 NullPointException을 방지하는 방향으로 경각심을 가지자
최대한 발생하지 않는방향으로 작성해야한다.
메서드 설계 시 return null을 자제하자 (어렵다면 Optional 사용을 고려)
Optional에 관하여
Optional은 비싼 객체이다, 꼭 필요한 상황에서 반환타입으로만 사용하자
파라미터로는 분기케이스가 3개나 됨으로 되도록이면 파라미터로 받지 않도록 하자
만약 어쩔수 없이 반환 받았다면 최대한 빠르게 해소할수 있도록 한다.
Optional을 해소하는 방법
분기문을 만드는 isPresent()-get() 대신 API를 사용한다
ex) orElseGet(), orElseThrow(), ifPresent(), ifPresentOrElse()
orElse()
-> 항상 실행, 확정된 값일 때 사용
orElseGet()
-> null인경우 실행, 값을 제공하는 동작(Supplier)정의
orElseThrow()
->있으면 쓰고 없으면 예외를 던진다
차이를 숙지해놓자.
'인프런 > Readable Code: 읽기 좋은 코드를 작성하는 사고법 리뷰' 카테고리의 다른 글
섹션 4 : 객체 지향 패러다임 (0) | 2024.11.24 |
---|---|
섹션 2 : 추상(抽象) (1) | 2024.11.17 |