반복되는 코드를 작성하지 않는다.

• 단, 테스트코드는 예외로 한다.

변수는 최대한 사용하는 위치에 가깝게 사용한다.

파라미터 변수와 내부 변수를 구별할 땐 언더바가 아닌 this로 구별한다.

• this.name = name (O) / name = _name (X)
• 추가적으로 언더바를 prefix로 사용하는 것을 지양하자.

코드의 길이가 짧고 명료한 것도 좋지만, 가독성이 현저히 떨어진다면 코드를 좀 더 풀어쓴다.

• 무조건적으로 코드가 짧은 것이 좋다고 생각하지 않는다. 다른 개발자가 본다면 가독성이 현저히 떨어진다.
• 특히나 최신 언어(kotlin 등)의 경우 코드의 길이를 현저히 줄일 수도 있지만, 제3자의 입장에서 봐도 어느정도 가독성이 있는지 다시 한번 확인하는 작업을 하자.

모든 예외는 무시하지말고 처리한다. 만약 예외를 처리하지 않을거라면 그 이유에 대해서 명확하게 주석을 남긴다.

예외를 던질 때는 최대한 세부적인 Exception(= Custom Exception)을 던진다.

• 실패한 코드의 의도를 파악하려면 호출 스택트레이스만으로 부족하다.
• 오류 메세지에 전후 상황의 정보를 담아 예외와 함께 던진다.

예외 케이스가 발생할 확률이 있는 경우, 가능한 빨리 리턴 또는 예외를 던지도록 작성한다.

• 쓸데없이 정상로직을 태울 필요가 없게한다.

  if(!정상) {
    throw err;
  }
  정상 로직
  }
  

조건이 복잡한 경우 임시 boolean 변수를 만들어 단순화한다.

조건문에 부정조건을 넣는 것을 피한다.

• if(status.isNormal()) (O) / if(!status.isAbnormal()) (X)

최대한 객체 타입 대신 기본 자료형을 선택하고, 생각지도 못한 Autoboxing이 발생하지 않도록 유의한다.