자바 컨벤션 정리

자바 컨벤션

---

1. 기능 목록 구현을 재검토한다

기능 목록을 클래스 설계와 구현, 함수(메소드) 설계와 구현과 같이 너무 상세하게 작성하지 않는다. 클래스 이름, 함수(메소드) input/output은 언제든지 변경될 수 있기 때문이다. 너무 세세한 부분까지 정리하기 보다 구현해야할 기능 목록을 정리하는데 집중한다. 정상적인 경우도 중요하지만 예외적인 상황도 기능 목록에 정리한다. 특히 예외 상황은 시작단계에서 모두 찾기 힘들기 때문에 기능을 구현하면서 계속해서 추가해 나간다.

---

2. 값을 하드코딩하지 마라

문자열, 숫자 등의 값을 하드코딩하지 마라. 상수(static final)를 만들고 이름을 부여해 이 변수의 역할이 무엇인지 의도를 드러내라. 구글에서 java 상수와 같은 키워드로 검색해 상수 구현 방법을 학습하고 적용해 본다.

---

3. 축약하지 마라

의도를 드러낼 수 있다면 이름이 길어져도 괜찮다.

---

4. java api를 적극 활용한다

메소드를 직접 구현하기 전에 java api에서 제공하는 기능인지 검색을 먼저 해본다. java api에서 제공하는 않을 경우 직접 구현한다.

---

5. 배열 대신 java collection을 사용하라

java collection 자료구조(List, Set, Map 등)를 사용하면 데이터를 조작할 때 다양한 api를 사용할 수 있다.

---

6. 객체에 메시지를 보내라

상태 데이터를 가지는 객체에서 데이터를 꺼내려(get)하지 말고 객체에 메시지를 보내라

---

7. 필드(인스턴스 변수)의 수를 줄이기 위해 노력한다

필드(인스턴스 변수)의 수가 많은 것은 객체의 복잡도를 높이고, 버그 발생 가능성을 높일 수 있다. 필드(인스턴스 변수)에 중복이 있거나, 불필요한 필드가 없는지 확인해 필드의 수를 최소화한다.

---

8. 비지니스 로직과 UI 로직을 분리해라

비지니스 로직과 UI 로직을 한 클래스가 담당하지 않도록 한다.
단일 책임의 원칙에도 위배된다.
현재 객체의 상태를 보기 위한 로그 메시지 성격이 강하다면 toString()을 통해 구현한다. View에서 사용할 데이터라면 getter 메소드를 통해 데이터를 전달한다

---

9. 함수(메소드) 라인에 대한 기준

프로그래밍 요구사항을 보면 함수 15라인으로 제안하는 요구사항이 있다. 이 기준은 main() 함수에도 해당된다. 주석은 가능하면 함수 밖 또는 코드 우측에 추가하는 방식으로 구현한다. 공백 라인도 한 라인에 해당한다.

---

10. 발생할 수 있는 예외케이스에 대해 고민한다

정상적인 경우를 구현하는 것보다 예외 상황을 모두 고려해 프로그래밍하는 것이 더 어렵다. 예외 상황을 고려해 프로그래밍하는 습관을 들인다.

---

11. 주석은 꼭 필요한 경우만 남긴다

메서드의 역할이 무엇인지는 메서드의 이름으로, 변수의 역할이 무엇인지는 변수의 이름으로 알 수 있어야 한다. 주석은 꼭 필요한 것이 아니면 남기지 않는다.

---

12. git을 통해 관리할 자원에 대해서도 고려한다.

.class 파일은 java 코드가 있으면 생성할 수 있다. 따라서 .class 파일은 굳이 git을 통해 관리하지 않아도 된다. intellij의 .idea 폴더, eclipse의 .metadata 폴더 또한 개발 도구가 자동으로 생성하는 폴더이기 때문 에 굳이 git으로 관리하지 않아도 된다. 앞으로 git에 코드를 추가할 때는 git을 통해 관리할 필요가 있는지 여부를 고려해볼 것을 추천한다.

---

13. 이름을 통해 의도를 드러내라.

변수 이름, 함수(메소드)이름, 클래스 이름을 짓는데 시간을 투자하라. 이름을 통해 변수의 역할, 함수의 역할, 클래스의 역할에 대한 의도를 드러내기 위해 노력하라. 연속적인 숫자를 덧붙인 이름(a1, a2, …, aN) 덧붙이거나 불용어(Info, Data, a, an, the)를 추가하는 방식은 적절하지 못하다.

---

14. space(공백)도 convention이다.

for, while, if문 사이의 space도 convention이다.

---

15. 불필요하게 공백 라인을 만들지 않는다.

공백 라인을 띄우는 것도 코드상에 문맥이 달라지는 부분에 의도를 가지고 띄우면 좋겠다.

---

16. 구현 순서도 convention이다

클래스의 구현 순서에 대한 convention을 지키는 것도 읽기 좋은 코드를 구현하는데 의미가 있다. 클래스의 구현 순서를 지키면서 프로그래밍한다.

---

17. 반복하지 마라.

중복은 소프트웨어에서 모든 악의 근원이다.

---

18. space vs tab 혼용

들여쓰기에 space와 tab을 혼용하지 않는다. 둘 중에 하나만 사용한다. 확신이 서지 않으면 pull request를 보낸 후 들여쓰기가 잘 되어 있는지 확인하는 습관을 들인다.

---

19. git commit 메시지를 의미있게 작성

commit 메시지에 해당 commit에서 작업한 내용에 대한 이해가 가능하도록 작성한다.

---

20. 기능 목록 업데이트

README.md 파일에 작성하는 기능 목록은 기능 구현을 하면서 변경될 수 있다. 시작할 때 모든 기능 목록을 완벽하게 정리해야 한다는 부담을 가지기 보다 기능을 구현하면서 문서를 계속 업데이트한다. 죽은 문서가 아니라 살아있는 문서를 만들기 위해 노력한다.

---

21. READEME.md를 상세히 작성

저장소의 README.md는 소스코드에 앞서 해당 프로젝트가 어떠한 프로젝트인지 마크다운으로 작성하여 소개하는 문서이다. 해당 프로젝트가 어떠한 프로젝트이며, 어떤 기능을 담고 있는지 기술하기 위해서 마크다운문법을 검색해서 학습해보고 적용해 본다.

---

22. indent(인덴트,들여쓰기) depth를 2가 넘지않도록 구현한다. 1까지만허용

예를들어 while문안에 if문이 있으면 들여쓰기는 2이다.

힌트 : indent(인덴트,들여쓰기) depth를 줄이는 좋은 방법은 함수(또는메소드)를 분리하면 된다.

---

23. else 예약어를 쓰지 않는다.

힌트 : if 조건절에서 값을 return하는 방식으로 구현하면 else를 사용하지 않아도 된다.
else를 쓰지 말라고 하니 switch/case로 구현하는 경우가 있는데 switch/case도 허용하지 않는다.

---

24. 함수(또는 메소드)의 길이가 10라인을 넘어가지 않도록 구현한다.

함수(또는메소드)가 한 가지 일만 잘하도록 구현한다.

---

25. 블럭 들여쓰기: +4 스페이스

새 블록 또는 블록과 유사한 구조(block-like construct)가 열릴 때마다 들여쓰기가 네 칸씩 증가합니다. 블록이 끝나면 들여쓰기는 이전 들여쓰기 단계로 돌아갑니다. 들여쓰기 단계는 블록 전체의 코드와 주석 모두에 적용됩니다.

---

26. 열 제한: 120

Java 코드의 열 제한은 120자입니다. “문자”는 유니코드 코드 포인트를 의미합니다.

---

27. 들여쓰기 지속은 최소 +8 스페이스

줄 바꿈 시 그 다음 줄은 원래 줄에서 +8 이상 들여씁니다.

---

28. 수직 빈 줄

빈 줄은 가독성을 향상시키기 위해서라면 어디든(예를 들면 논리적으로 코드를 구분하기 위해 문장 사이) 사용 될 수 있습니다. 클래스의 첫 번째 멤버나 초기화(initializer) 또는 마지막 멤버 또는 초기화( initializer) 뒤의 빈 줄은 권장되지도 비권장하지도 않습니다.

클래스의 첫 번째 멤버나 초기화(initializer) 앞에 있는 빈줄을 강제하지 않습니다.

---

29. 소트웍스 앤솔리지 - 일급 콜렉션을 활용해 구현한다.

컬렉션을 포함한 클래스는 반드시 다른 멤버 변수가 없어야 한다.

향로님 관련자료

---

30. 소트웍스 앤솔리지 - 모든 원시값과 문자열을 포장한다.

가독성을 위하여 객체로 wrapping 한다.

---

[참고]
우아한 테크코스