Ch6. 객체와 자료 구조 이 챕터는 전체적으로 잘 이해가 되지 않음 ㅜ 자료 추상화 클래스 혹은 함수 내의 변수와 같은 자료를 세세하게 공개하기 보다는 추상적인 개념으로 표현하는 편이 좋다. 인터페이스나 조회/설정 함수만으로는 추상화가 이뤄지지 않는다. 개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다. 아무 생각 없이 조회/설정 함수를 추가하는 방법이 가장 나쁘다. // 구체적인 Vehicle 클래스 public interface Vehicle { double getFuelTankCapacityInGallons(); double getGallonsOfGasoline(); } // 추상적인 Vehicle 클래스 public interface Vehicle { double ..

Ch5. 형식 맞추기 프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다. 코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다. 팀으로 일한다면 팀이 합의해 규칙을 정하고 모두가 그 규칙을 따라야 한다. 필요하다면 규칙을 자동으로 적용하는 도구를 활용한다. 형식을 맞추는 목적 코드 형식은 중요하다! 코드 형식은 의사소통의 일환. 의사소통은 전문 개발자의 일차적인 의무 적절한 행 길이를 유지하라 일반적으로 큰 파일보다 작은 파일이 이해하기 쉬움 e.g. 한 파일에 200줄 씩으로도 커다란 시스템을 구축할 수 있음 신문 기사처럼 작성하라 아주 좋은 신문 기사를 떠올려보라. 독자는 위에서 아래로 기사를 읽는다. 최상단에 기사를 몇 마디로 요약하는 표제가 나온다. 독자는 표제를 보고서..

Ch4. 주석 나쁜 코드에 주석을 달지 마라. 새로 짜라. 브라이언 W. 커니핸, P. J. 플라우거 잘 달린 주석은 그 어떤 정보보다 유용하다. 경솔하고 근거 없는 주석은 코드를 이해하기 어렵게 만든다. 사실상 주석은 기껏해야 필요악이다. 프로그래밍 언어 자체가 표현력이 풍부하다면, 아니 우리에게 프로그래밍 언어를 치밀하게 사용해 의도를 표현할 능력이 있다면, 주석은 거의 필요하지 않으리라. 아니, 전혀 필요하지 않으리라. 우리는 코드로 의도를 표현하지 못해, 그러니까 실패를 만회하기 위해 주석을 사용한다. 그러므로 주석이 필요한 상황에 처하면 곰곰이 생각하기 바란다. 상황을 역전해 코드로 의도를 표현할 방법은 없을까? 코드로 의도를 표현할 때마다 스스로를 칭찬해준다. 주석을 달 때마다 자신에게 표현력..

Ch3. 함수 작게 만들어라 함수를 만드는 첫째 규칙은 '작게!' 함수를 만드는 둘째 규칙은 '더 작게!' 얼마나 짧아야 하는가? 일반적으로 아래 예시 정도로 짧게 작성해야한다! public static String renderPageWithSetupsAndTeardowns( PageData pageData, boolean isSuite) throws Exception { if (isTestPage(pageData)) includeSetupAndTeardownPages(pageData, isSuite); return pageData.getHtml(); } 블록과 들여쓰기 즉, if / else / while 문에 들어가는 블록은 한 줄이어야 한다는 의미. 한 가지만 해라 함수..

Ch2. 의미 있는 이름 의도를 분명히 밝혀라 변수나 함수 그리고 클래스 이름은 다음과 같은 굵직한 질문에 모두 답해야 한다. 변수 (혹은 함수나 클래스)의 존재 이유는? 수행 기능은? 사용 방법은? 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 것 의미 있게 구분해라 컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하면 언젠가는 문제가 생기기 마련 연속된 숫자를 덧붙이거나 불용어(의미가 불분명하거나 없어도 되는 단어)를 추가하는 방식은 적절하지 못함 이름이 달라야 한다면 의미도 달라져야 한다. 변수의 이름으로 아무런 정보를 제공 받지 못하는 예시 public static void copyChars(char a1[], char a2[]){ for (int i = 0; i < a1.lengt..