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

첫 번째 장 : 좋은 이름 붙이기 피해야 하는 명명법 그릇된 정보 피하기 - 실제 List가 아닌 변수를 -List라 명하지 않기 의미없는 변수명 피하기 - a1, a2, a3 같은 연속적인 숫자를 덧붙인 이름이나, Info, Data와 같이 의미가 불분명한 용어 추가하지 않기(Product와 ProductInfo의 차이는? 구분 못함…) 발음하기 어려운 이름 검색하기 어려운 이름(ex: 한 글자짜리 이름) - 한 문자 이름은 간단한 메서드에서 로컬 변수일 때만.(이름 길이는 범위 크기에 비례해야 한다) 인코딩한 이름 본인만 기억하는 이름 기발한 이름 추천하는 명명법 클래스/객체 : 명사나 명사구 사용하기. Manager, Processor, Data, Info 등과 같은 단어는 피하고 동사는 사용하지 ..

코드를 클린하게 짜는 게 기능을 빨리 완성하는 것보다 중요한가요? 코딩하는 모습을 녹화한 편집 세션을 재생해보면, 코드를 읽는 시간이 코드를 짜는 시간의 열 배를 넘김 새 코드를 짜는 과정에서 우리는 계속 기존 코드를 읽는다. => 코드가 읽기 쉬우면 새 코드를 짜기도 쉽다! 코드 퀄리티 보존을 위한 규칙 : 보이스카우트 규칙 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라. 첫 번째 장 : 좋은 이름 붙이기 의도를 분명히 밝히기 int d; 처럼 아무 의미도 없는 이름은 코드의 의도를 드러내지 못한다. 코드의 목적과 기능에 맞는 이름을 붙이면 이해하기가 훨씬 쉽다!

클린 코드란 무엇인가? 읽기 쉬운 코드 남이 고치기 쉬운 코드 한 가지 목적을 수행하는 코드 테스트 케이스가 있는 코드 나쁜 코드가 쌓일수록 개발 생산성은 0에 수렴한다.