Java Code Convention

  • 습관으로 만들기 위해 자바 코드 컨벤션을 적는다.
  • 최근에 우아한 테크코스를 진행하면서 더욱 느꼈다.
  1. 새줄 문자는 CRLF(Windows, /r/n)가 아닌 LF(Unix, /n)
    1. LF는 커서의 위치는 그대로 두고 종이를 한 라인 위로 올리는 동작을
    2. CR는 현재 라인에서 커서의 위치를 맨 앞으로 옮기는 동작을 의미했다고 한다.
    3. CR + LF 는 두 동작을 합해서, 커서를 다음 라인의 맨 앞으로 옮겨주는 것이었다.
  2. 한국어 발음대로 표기 금지
  3. 반복하지 마라.
  4. 의미없는 주석은 달지 않는다.
    1. 주석은 가능하면 함수 밖 또는 코드 우측에 추가한다.
    2. 주석은 꼭 필요한 경우에만 남긴다.
  5. 값을 하드코딩하지 마라.
    1. 최대한 상수화를 한다.
    2. 상수(static final)를 만들고 이름을 부여해 이 변수의 역할이 무엇인지 의도를 드러내라.
    3. 구글에 “java 상수”와 같은 키워드로 검색해 상수 구현 방법을 학습하고 적용하자.
  6. 테스트 클래스는 Test로 끝남
  7. 상수는 대문자와 언더스코어
  8. 변수나 메소드는 소문자 카멜 표기법
    1. 이름을 통해 의도를 드러내라.
    2. 변수 이름, 메소드 이름, 클래스 이름을 짓는데 시간을 투자하라.
    3. 연속적인 숫자를 덧붙인 이름이나 불용어(Info, Data, a, an, the)를 추가하는 방식은 적절하지 못하다.
  9. 임시 변수 외 1글자 금지 또는 함수 이름
    1. 축약하지 마라.
    2. 의도를 드러낼 수 있다면 이름이 길어져도 괜찮다.
  10. 소스 파일당 한 개의 탑 레벨 클래스(내부 클래스는 선언 가능)
  11. 제한자 선언 순서 : public protected private abstract static final transient volatile synchronized native strictfp
  12. 배열에서 대괄호는 타입 뒤에 선언
  13. long 형 값 마지막에 L 붙이기
  14. 1개의 tab = 4개의 space
  15. 중괄호 선언은 K & R 스타일
  16. 줄바꿈 허용 위치
    1. extends 선언 후
    2. implements 선언 후
    3. throws 선언 후
    4. 시작 소괄호(() 선언 후
    5. 콤마(,) 후
    6. . 전
    7. 연산자 전
  17. 모든 줄은 탭이나 공백으로 끝내지 않는다.
    1. 공백도 convention이다.
    2. space와 tab을 혼용하지 않는다.
    3. 불필요한 공백 라인을 만들지 않는다.
  18. 대괄호 뒤 공백 삽입(int[] mask = new int[] {0, 1, 1})
  19. 콜론 앞 뒤에 공백 삽입( : )
  20. 구현 순서도 convention이다. 
    1.  class A{
     상수(static final) 또는 클래스 변수
     인스턴스 변수
     생성자
     메소드
 }
  21. 코딩컨벤션 검사 도구(Code format)를 사용하자.
  22. README.md 파일에 작성하는 기능 목록은 기능을 구현하면서 문서를 계속 업데이트 한다.
    1. 죽은 문서가 아니라 살아있는 문서를 만들기 위해 노력한다.
    2. 기능 목록은 너무 상세하게 작성하지 않는다.
    3. 상세하게 작성하지 말고 정말 구현해야할 기능 목록을 작성한다.(ex. 이름이 5이하인지 검증한다)
    4. 정상적인 경우도 중요하지만 예외적인 상황도 기능 목록에 정리한다.(추가해나간다)
  23. java api를 적극 활용한다.
    1. 메소드를 직접 구현하기 전에 java api에서 제공하는 기능인지 검색해본다.
    2. 배열 대신 Java Collection을 사용하라.
  24. 객체에 메세지를 보내라
    1. 상태 데이터를 가지는 객체에서 데이터를 꺼내려(get) 하지 말고 객체에 메세지를 보내라.
    2. 예를 들어 isMaxPosition(Car car){}라는 메소드를 만들어 객체 Car를 보내 maxPosition을 알려고 하지말고 Car 객체 안에 isMaxPosition(){}라는 메소드를 만들어 객체.isMaxPosition(maxDistance)와 같이 Car 객체에 메세지를 보내 구현한다.
  25. 필드(인스턴스 변수)의 수를 줄이기 위해 노력한다. 이는 객체의 복잡도를 높이고, 버그 발생 가능성을 높일 수 있다.
  26. 비즈니스 로직과 UI 로직을 분리해라.
  27. 현재 객체의 상태를 보기 위한 메세지의 성격이 강하다면 toString()을 통해 구현하고, View에서 사용할 데이터가 필요하다면 getter 메소드를 통해 데이터를 전달한다.
  28. 함수를 15라인으로 제한하는 건 main함수도 포함이다.
    1. 공백도 한 라인에 해당한다.
  29. commit convention을 지키자
    1. github에서 commit 메세지의 #번호는 이슈 또는 PR을 참조할 때 사용한다.
  30. 발생할 수 있는 예외케이스에 대해 고민한다.
    1. 음수, 공백, 빈값 등등
  31. 시작 단계에서 너무 완벽한 설계를 하면 안 된다.
    1. 시작 단계는 요구사항에 대한 도메인 지식이 부족하므로 분석 가능한 상태로 설계 진행, 구현하면서 재설계하고 구현한다.
  32. 원시 타입과 문자열을 포장하라
    1. 숫자의 합을 Score라는 객체로 포장해라.
      1. 그 안에서 예외, 조건이 되는 숫자들을 static final로 지정해두고 생성자에 예외나 조건이 안된다면 예외를 던지는 식으로 코딩하자.
    2. y 또는 n의 값을 YesOrNo 객체로 포장
      1. 값을 받아서 NULL이라면, 글자 수가 2 이상이라면, 다른 문자가 나온다면 등등으로 조건을 줘서 예외를 던져도 된다.
  33. Collection을 객체로 포장한다
    1. 그 Collection 이외에 다른 필드가 없게 하고 작성한다.
  34. 객체에 메시지를 보내라.
    1. 상태 데이터를 가지는 객체에서 데이터를 꺼내려(get)하지 말고 객체에서 메시지를 보내라.
  35. 어떤 객체로 추상화한다고 했을 때 그 객체에 대한 로직을 그 객체에게 모든 책임을 지도록 한다.
    1. Score 객체가 점수 계산 로직을 책임진다고 했을 때 카드 점수든, 뭐든 계산 로직은 모두 Score 객체에게 준다.
  36. enum도 자바 객체와 같다. 값을 꺼내지(get) 하지 말고 메시지를 보내 로직을 구현한다.
  37. 함수의 depth를 최대 2로 두고 가능하다면 1로 구현하도록 노력하자(함수를 분리하자)
  38. 비즈니스 로직과 UI로직을 분리해라.
  39. 한 메서드에 오직 한 단계의 들여쓰기(indent 1)만 한다.
  40. else 예약어를 쓰지 않는다.
  41. 한 줄에 점을 하나만 찍는다.
  42. 모든 엔티티를 작게 유지한다.
  43. 2개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
  44. 일급 콜렉션을 쓴다.
  45. Getter(게터)/Setter(세터)/프로퍼티를 쓰지 않는다.

출처

  • https://ohgyun.com/554
  • https://naver.github.io/hackday-conventions-java/
  • 우아한 테크코스 프리코스 피드백