이름을 통해 의도를 드러내자
변수 이름, 메서드 이름, 클래스 이름을 짓는데 시간을 투자하자!
나 자신과 다른 개발자와의 소통을 위한 중요한 시간이다. 이름을 통해 변수/함수/클래스의 역할에 대한 의도를 드러내도록 하자.
축약 X
클래스와 메서드 이름을 한 두 단어로 유지하려고 노력하고 문맥을 중복하는 이름을 자제 하자.
클래스 이름이 Order라면 shipOrder라고 메서드 이름을 지을 필요가 없다.
공백
if, for, while 문 사이의 공백도 코딩 컨벤션이다.
공백 라인을 의미 있게 사용하자
공백 라인을 의미 있게 사용하는 것이 좋아 보이고, 문맥을 분리하는 부분에 사용하는 것이 좋다.
반복하지 말자
소프트웨어를 신뢰성 높게 개발하고, 개발을 이해하고 유지보수하기 쉽게 만드는 유일한 길은 우리가 DRY 원칙이라고 부르는 것을 따르는 것뿐이라 생각한다.
D(o not) R(epeat) Y(ourself)!
소스코드에서 동일한 코드가 반복이 된다는 것은 잠재적인 버그의 위협을 증가시킨다. 반복되는 코드 내용이 변경될 필요가 있는 경우, 반복되는 모든 코드를 찾아 수정해야 한다. 이 과정에서 실수가 있다면 버그가 발생하게 된다.
프로젝트 규모가 커질수록 반복되는 코드로 인한 유지 보수 오버헤드가 커진다.
코드에서 중복을 발견할 때마다 추상화할 기회로 간주하라. 중복된 코드를 하위 루틴이나 다른 클래스로 분리하라. 이렇듯 추상화로 중복을 정리하면 설계 언어의 어휘가 늘어난다. 다른 프로그래머들이 그만큼 어휘를 사용하기 쉬워진다. 추상화 수준을 높였으므로 구현이 빨라지고 오류가 적어진다
커밋 메시지를 의미 있게 작성하자
커밋 메시지에 해당 커밋에서 작업한 내용에 대해 이해가 가능하도록 작성하자.
기능 목록을 업데이트하자
기능을 구현하면서 문서를 계속 업데이트하자. 죽은 문서가 아닌 살아있는 문서를 만들기 위해 노력하자!!
기능 목록을 재검토하자.
기능 목록을 클래스 설계와 구현, 메서드 설계와 구현과 같이 너무 상세하게 작성하지 말자.
클래스 이름, 메서드 시그니처와 반환값은 언제든지 변경될 수 있다.
구현해야 할 기능 목록을 정리하는 데 집중하자!
정상적인 것도 중요하지만, 예외적인 상황도 기능 목록에 정리 하도록 하자.
특히 예외 상황은 시작 단계에서 모두 찾기 힘들기 때문에 기능을 구현하면서 계속해서 추가해나가자
매직 넘버를 사용하지 말자
매직 넘버는 의미를 나타낼 수 있는 상수 (static final)로 치환하여 코드의 가독성을 높이자.
프로그래밍에서 상수(static final)로 선언하지 않은 숫자를 매직 넘버, 문자열을 매직 리터럴이라 한다.
코드에서 상수로 선언되어 있지 않은 숫자, 문자열은 무엇을 의미하는지 확신할 수 없다.
따라서 그 의미를 파악하기 위해 클래스를 이해하고, 코드의 흐름을 이해하기 위한 시간과 노력이 필요하게 된다.
이를 상수로 선언하게 됨으로써 불분명한 값들은 이름을 가지게 된다.
이름을 가지게 된 값은 그 이름만으로도 어떠한 역할을 하는지 알 수 있게 된다.
단, 숫자 1을 ONE으로 이름을 짓는 것과 같은 의미없는 상수 변환은 피하도록 하자.
구현 순서도 코딩 컨벤션이다
클래스는 상수, 멤버 변수, 생성자, 메서드 순으로 작성하자.
class A {
상수(static final) 또는 클래스 변수
인스턴스 변수
생성자
메서드
}