디미터 법칙 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙. => C 클래스의 메서드 f는 다음 객체의 메서드만 호출해야 한다는 법칙 - 클래스 C - f가 생성한 객체 - f 인수로 넘어온 객체 - C 인스턴스 변수에 저장된 객체 예를 들어, final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath() 위 코드는 객체의 메서드를 두 번 중첩해서 호출하므로 디미터 법칙을 어김. 위와 같은 코드는 기차 충돌이라 부르며, 일반적으로 피하는 편이 좋다. 객체라면 내부 구조를 숨겨야 하므로 디미터 법칙이 적용되지만, 자료 구조는 기본적으로 내부 구조를 노출하므로 디미터 법칙이 적용되지 않는다. 즉 다음과 같은 코드는 디미터..

들여쓰기 범위로 이뤄진 소스 계층을 표현하기 위해 코드를 들여씀 => 들여쓰기는 가독성을 향상시킨다. 들여쓰기 무시하기 if, while문을 쓰면서 한 행에 범위를 뭉뚱그리는 것은 좋지 않다. 가짜 범위 빈 while문이나 빈 for 문은 피한다. 팀 규칙 팀은 한 가지 규칙에 합의해야 하고, 모든 팀원은 그 규칙을 따라야 한다. => 소프트웨어가 일관적인 스타일을 보일 수 있도록. 객체와 자료 구조 자료 추상화 구현을 감추려면 추상화가 필요함 형식 논리에 치우쳐 getter/setter로 변수를 다룬다고 클래스가 되지는 않음 => 추상 인터페이스를 사용해 구현을 몰라도 자료의 핵심을 조작할 수 있어야 진정한 클래스. 아무 생각 없이 getter/setter를 추가하는 방법은 나쁘다. 자료/객체 비대칭 ..

인스턴스 변수 인스턴스 변수는 클래스 맨 처음에 선언하고, 변수 간에 세로로 거리를 두지 않는다. => 언어마다 인스턴스 변수를 선언하는 위치는 다를 수 있지만, 잘 알려진 위치에 인스턴스 변수를 모은다는 점은 같으며 그 점이 중요하다. 종속 함수 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치하며, 가능하다면 호출하는 함수를 호출되는 함수보다 먼저 배치한다. => 프로그램이 자연스럽게 읽히기 위함 + 규칙을 일관적으로 적용하면 독자는 방금 호출한 함수가 잠시 후에 정의되리라는 사실을 예측한다. 개념적 유사성 개념적인 친화도가 높을수록 코드를 가까이 배치한다. 친화도가 높은 경우 : 한 함수가 다른 함수를 호출할 때(종속성), 변수와 그 변수를 사용하는 함수, 비슷한 동작을 수행하는 일군..

형식 맞추기 형식을 맞추는 목적 코딩하기 전에 코드 형식을 맞추기 위한 규칙을 정하는 것이 좋다. -> 코드가 바뀌어도 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수에 계속 영향을 미친다. 좋은 코드 형식 적절한 행 길이를 유지하기 큰 파일보다 작은 파일이 이해하기 쉽다. 대부분 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있음 신문 기사처럼 작성하기 이름은 간단하면서도 설명 가능하게 짓기 소스 파일 첫 부분은 고차원 개념과 알고리즘, 아래로 내려갈수록 저차원 함수와 세세하게 묘사하는 코드 -> 위에서 아래로 읽을 수 있게 하기(기사에서 첫 문단이 전체 기사 내용을 요약하고, 세세한 사실은 내려갈수록 드러나듯이) 다양한 파일로 구성하기 - 신문은 다양한 기사로 이뤄진다. 개념은 빈 행으로 분..

나쁜 주석 함수나 변수로 표현할 수 있는 주석 : 주석을 통해 코드를 이해시키기보다, 주석이 필요하지 않도록 코드를 개선하는 편이 좋다. 위치를 표시하는 주석 : 배너 역할을 하는 주석. 배너를 남용하면 흔한 잡음으로 여겨지므로, 반드시 필요할 때만 드물게 사용하라. 닫는 괄호에 다는 주석 : 닫는 괄호 뒤에 어떤 블록이었는지 표시하는 주석. } // while, } // try 같은 것들. 중첩이 심하고 장황한 함수라면 도움이 될지도 모르지만 작게 잘 나누어진 함수들에선 잡음이다. 그러므로 닫는 괄호에 주석을 달기보다 함수를 쪼개고 줄여 보자. 공로를 돌리거나 저자를 표시하는 주석 : 소스 코드 관리 시스템에 저장하자. 주석으로 처리한 코드 : 좋지 않은 관행이다. 주석으로 처리한 코드는 다른 사람들이..

좋은 주석 중요성을 강조하는 주석 공개 API에서 Javadocs 나쁜 주석 대다수 주석이 나쁜 주석이다. 주절거리는 주석 : 특별한 이유 없이 의무감으로 마지못해 주석을 다는 경우. 다른 사람들에게 그 의미가 잘 전해지지 않는 주석. 이해가 안 되어 다른 모듈을 뒤져야 하는 주석. 같은 이야기를 중복하는 주석 : 코드 내용을 그대로 중복하는 주석. 코드보다 주석을 읽는 시간이 오래 걸릴 수 있다. 주석은 코드보다 더 많은 정보를 제공해야 한다. 오해할 여지가 있는 주석 : 중의적이거나, 모호하거나… 의무적으로 다는 주석 : 필요가 없는데도 모든 변수에 주석이 달려 있거나 한 경우. 코드를 복잡하게 만들고, 코드 업데이트를 주석이 따라가지 못해 잘못된 정보를 제공할 수 있다. 이력을 기록하는 주석 : 소..

주석 주석은 필요악이다 - 쓰지 않아도 되는 곳엔 쓰지 않는 게 좋다. 주석은 오래될수록 코드에서 멀어진다. -> 주석까지 유지보수하는 건 힘들기 때문. 주석은 나쁜 코드를 보완하지 못한다 코드 품질이 나쁠 땐 주석을 추가하기보다 코드를 정리해야 한다. 코드로 의도를 표현하라! 주석으로 달려는 설명을 코드로 충분히 표현할 수 있다. 좋은 주석 어떤 주석은 유익할 수도 있다. 하지만, 주석이 없는 게 제일 완벽하다… 법적인 주석 : 라이선스 등을 표시한 것 정보를 제공하는 주석 : 코드를 통해 설명하기 힘든 정보를 제공하는 주석. 의도를 설명하는 주석 : 구현 결정에 깔린 의도를 설명 가능. 의미를 명료하게 밝히는 주석 : 모호한 인수나 반환값을 변경하지 못할 경우, 주석으로 밝힐 수 있음(but, 그릇된..

오류 코드보다 예외 사용하기 오류 코드를 반환하면 호출자가 오류 코드를 처리해야 한다. But 예외를 사용하면 오류 처리 코드가 원래 코드에서 분리되므로 코드가 깔끔해진다. Try/Catch 블록 뽑아내기 try/catch는 추하므로 별도 함수로 뽑아내자. 오류 처리도 한 가지 작업! Error.java 의존성 자석 의존성 자석 : 다른 클래스에서 많이 사용해서 만약 변경된다면, 이를 사용하는 클래스 전부를 다시 컴파일하고 배치해야 하는 값 -> 오류 코드를 반환한다는 이야기는 오류 코드를 정의하여 의존성 자석을 만들어낸다는 것이므로, 예외를 사용하자. 반복하지 마라! 중복은 소프트웨어의 모든 악의 근원이다. 수정이 어렵고 오류 발생 확률도 높아진다. 구조적 프로그래밍 다익스트라는 모든 함수와 함수 안의..

두 번째 장 : 함수 내려가기 규칙 코드는 위에서 아래로 이야기처럼 읽혀야 좋다. => 뒤로 갈수록 추상화 수준이 낮은 함수가 오도록 한다.(앞에서 쓴 함수를 뒤에서 설명하도록) switch 문 다형성을 이용해 switch문을 저차원 클래스에 숨기고 같은 구조를 반복하지 않게 할 수 있다. 서술적인 이름 사용하기 이름이 길어도 괜찮으니 함수가 하는 일을 잘 설명하는 좋은 이름을 지어 주자. 이름을 지을 때는 일관성 있는 단어를 사용한다. 함수 인수 인수는 적을수록 좋다. 3항 이상의 인수는 피하는 편이 좋다. 출력 인수는 지양한다. 입력 인수가 아예 없거나, 1개뿐인 경우가 바람직하다. 많이 쓰는 단항 형식 인수에 질문을 던지는 경우(ex: boolean fileExists(“MyFile”)) 인수를 뭔..

첫 번째 장 : 좋은 이름 붙이기 의미 있는 맥락 추가하기 주소에서 쓰는 변수를 firstName, lastName, state로 짓는다면, state만 봤을 때 주소 일부라는 사실을 알아채기 힘듦 -> addr이라는 접두어를 추가하거나, Address라는 클래스를 생성하여 맥락 추가하기 불필요한 맥락 없애기 없어도 되는 무의미한 맥락을 추가하지 말 것 의미가 분명한 경우에 한해 짧은 이름이 긴 이름보다 좋다. 두 번째 장 : 함수 읽기 쉽고 이해하기 쉬운 함수를 만들어야 한다. 작게 만들기 함수는 적은 줄로 이루어질수록 좋다. if/else/while문의 블록은 한 줄로 이루어져야 한다. 함수에서 중첩 구조가 생기면 안 된다. 한 가지만 하기 함수는 한 가지만을 해야 한다. 지정된 함수 이름 아래에서 ..