iDrogba

형식을 맞추는 목적 - 코드 형식은 의사소통의 일환이다. - 처음 잡아놓은 구현 스타일은 코드에 계속 영향을 줌. 적절한 행 길이를 유지하라 - 일반적으로 큰 파일보다 작은 파일이 이해하기 쉬움. 신문기사처럼 작성하라 - 기사의 첫 문단은 전체 기사 내용을 요약한다. 코드에선 그 역할을 이름이 한다. 이름만 보고도 올바른 모듈을 살펴보고 있는지 아닌지를 판단할 정도로 신경 써서 짓는다. - 아래로 내려갈수록 세세하게 묘사하기. 마지막에는 가장 저차원 함수와 세부 내역이 나와야함. 개념은 빈 행으로 분리하라 - 개념 사이는 빈 행을 넣어 분리해야함. ex. 패키지 선언부, import문, 각 함수 사이 - 하나의 개념 덩어리가 한 덩어리로 보이도록. 세로 밀집도 - 줄바꿈이 개념을 분리한다면 세로 밀집도는..

4장 주석 - 부정확한 주석은 아예 없는 주석보다 훨씬 더 나쁘다. - 주석을 유지 보수하기란 현실적으로 어렵기에 시간이 지날수록 완전히 그릇될 가능성이 높다. 잘못된 정보를 전달하는 주석이 되는것이다. - 코드만이 자기가 하는 일을 진실되게 말한다. 코드만이 정확한 정보를 제공하는 유일한 출처다. - 그러므로 우리는 간혹 필요한 예외적인 상황을 제외하곤 주석을 줄이도록 노력해야 한다. 주석은 나쁜 코드를 보완하지 못한다. 코드로 의도를 표현하라! - 코드에 주석을 다는 이유?? 코드 품질이 나쁘니까. - 주석 달 시간에 코드를 고쳐! - 많은 경우 주석으로 달려는 설명을 함수로 만들어 표현해도 충분하다. 좋은 주석 - 법적인 주석 - 정보를 제공하는 주석 - 의도를 설명하는 주석 - 의미를 명료하게 밝..

3장 함수 의도를 분명히 표현하는 함수가 목표 * 작게 만들어라! - 함수가 후술할 원칙들을 만족하는 선에서 최대한 작게 만드는게 좋다. - 블록과 들여쓰기 if문/else문/while문에 들어가는 블록은 한줄이어야 한다. 대개 그 한줄에서 함수를 호출한다. 이로써 해당 함수 자체가 작아지고 함수에 중첩 구조가 생길만큼 커지는 것을 방지할 수 있다. 들여쓰기 수준은 1단 혹은 2단을 넘어서면 안 된다. * 한 가지만 해라! - 함수는 한가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. - 한가지 작업만 수행하는 함수 판별법 지정된 함수 이름 아래에서 추상화 수준이 하나인 단계들만 수행하는지? ( 함수는 점점 세부적인 깊이에서 여러번의 작업을 하는 방향으로 분화됨. 여기서 세부..

2장 의미 있는 이름 * 의도가 분명한 이름 - 변수, 함수, 클래스 등의 이름은 존재 이유, 수행 기능, 사용 방법 등의 의도를 알 수 있게 지어야한다. ex) 1 int d; // 경과 시간(단위 : 날짜) cs 의도를 전혀 드러내지 못하는 이름 1 2 3 4 5 6 7 int elapsedTimeInDays; int daysSinceCreation; int daysSinceModification; int fileAgeInDays; cs 의도가 충분히 드러나는 이름 * 그릇된 정보를 피하라 - 코드에 남겨진 잘못된 단서는 코드 의미를 흐린다. - ex) 배열로 구현된 그룹을 accountList로 이름 짓는 경우. 단순히 Accounts로 명명하는게 옳음. - 서로 흡사한 이름은 피한다. - 유사한 ..

* 코드는 요구사항을 상세히 표현하는 수단이다. * 나쁜 코드는 나쁜 코드를 낳는다. 이 악순환이 계속될수록 생산성은 떨어지고 마침내 0에 수렴한다. * 코드의 품질은 프로그래머의 첫번째 책임이다. - 기한과 요구사항에 쫓겨 겨우 돌아가기만 하는 코드를 짜는 것은 결국엔 더 큰 작업부하로 이어진다. * 깨끗한 코드 - 누가 읽더라도 읽기에 편한 코드 (ex.가독성). - 추측이 아닌 사실에 기반하여 반드시 필요한 내용만 담는 코드. - 세세한 사항까지 꼼꼼하게 손이 닿아 있는 코드 (ex.오류 처리). * 이 책에서 다룰 큰 원칙 - 중복 금지 - 한 기능만 수행 - 명확한 표현 - 작게 추상화