오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려워도, 맨 처음 잡아놓은 구현 스타일과 가독성은 유지보수 용이성과 확장성에 계속 영향을 미친다.
원래 코드는 사라질지라도 개발자의 스타일과 규율은 사라지지 않는다.
일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다.
독자는 위에서 아래로 읽으므로 신문 기사처럼 작성한다.
일련의 행 묶음은 완결된 생각 하나를 표현한다. 따라서 생각 사이에는 빈 행을 넣어 분리하자.
연관되어 있는 함수들은 밀접하게 적는다. 미로 같은 코드로 뺑뺑이 도는 것을 방지하자.
변수는 사용하는 위치에 최대한 가까이 선언한다.
지역 변수는 각 함수 맨 처음에 선언한다.
인스턴스 변수는 클래스 맨 처음에 선언한다. 코드 중간에 인스턴스 변수가 위치하면 찾기 힘들다.
한 함수가 다른 함수를 호출한다면 두 함수는 가깝게 배치한다.
또한 호출하는 함수를 먼저 배치한다.
친화도가 높은 함수들은 서로 가깝게 배치한다.
public static void assertTrue(String message, boolean condition) {
if (!condition) {
fail(message);
}
}
public static void assertTrue(boolean condition) {
assertTrue(null, condition);
}
public static void assertFalse(String message, boolean condition) {
assertTrue(message, !condition);
}
public static void assertFalse(boolean condition) {
assertFalse(null, condition);
}
아무리 모니터의 해상도가 높아졌다 하더라도 코드의 가로 길이가 너무 길면(120자 위로) 가독성이 낮아진다.
또한 한 개념이 아닌 별개의 경우에는 공백을 넣어 구분해줘야 가독성이 좋다. (쉼표, 연산자 우선순위 등)
가로 정렬은 오히려 코드의 엉뚱한 부분을 강조할 수 있다. 선언부가 너무 길다면 클래스를 쪼개는 선택을 하자.
들여쓰기가 없다면 인간이 코드를 이해하기 어려울 것이다. 하지만 들여쓰기가 너무 깊어도 가독성이 낮아진다.
들여쓰기를 무시하고픈 유혹이 생길 수도 있는데, 뭉뚱그린 코드는 피하자.
public String render() throws Exception {return "";}
빈 while 문, for 문의 경우 피하는 것이 맞지만, 피하지 못할 때는 개행 후 세미콜론으로 눈에 띄게 해준다.
while (dis.read(buf, 0, readBufferSize) != -1)
;
모든 팀원은 팀의 규칙을 따라야 한다.
스타일은 일관적이고 매끄러워야 한다. 한 소스 파일에서 봤던 형식이 다른 소스 파일에도 쓰이리라는 신뢰감을 독자에게 줘야 한다.