읽기 좋은 코드가 좋은 코드다(2016.03.27)

분량이 적으면 항상 좋은가?

 

이름에 정보를 담아라.

GetPage() 이 메소드는 로컬 캐시, 데이터베이스 아니면 인터넷 중 어디에서 페이지를 가져오는 것인가? 만약 인터넷에서 가져오는 것이라면 FetchPage() 혹은 DownloadPage()가 더 의미 있는 이름이 될 것이다.

 

Size() 메소드는 무엇을 반환할까? 트리의 높이, 노드의 개수, 아니면 메모리 사용량?

Height(), NumNodes(), MemoryBytes()

 

Stop()

최종 동작 수행 Kill(), Resume() 호출해서 다시 돌이이 킬 수 있는 동작 Pause()

 

단어	대안
send	deliver, dispatch, announce, distribute, route
find	search, extract, locate, recover
start	launch, create, begin, open
make	create, set up, build, generate, compose, add, new

 

 

 

함수	인수 단위를 포함하게 재작성
Start(int delay)	delay_secs
CreateCache(int size)	size_mb
ThrottleDownload(float limit)	max_kbps
Rotate(float angle)	degrees_cw

 

 

filter()

고르는 기능 select()

제거하는 기능 exclude()

 

경계를 포함하는 범위에는 first 와 last를 사용하라

start=2, stop=4 -& [2,3,4]

 

경계를 포함하고 배제하는 범위에는 begin과 end를 사용하라

(Oct 16 12:00 am, Oct 17 12:00am)

(Oct 16 12:00 am, Oct 17 11:59:59am)

 

불리언 변수에 이름 붙이기

일반적으로 is, has, can, should와 같은 단어를 더하면 불리언값의 의미

 

 

코드를 읽는 사람이 이미 친숙한, 일관성 있는 레이아웃을 사용하라

비슷한 코드는 서로 비슷해 보이게 만들어라

서로 연관된 코드는 하나의 블록으로 묶어라

 

미학적으로 보기 좋은 코드가 사용하기 더 편리하다는 사실은 명백하다.

 

class Logger{

...

};

 

혹은

 

class Logger

{

...

};

 

두 가지 스타일 중에 어느 하나를 선택한다고 가독성에 실질적인 영향을 주지는 않는다. 하지만 두 스타일이 뒤섞이면 가독성에 영향을 준다.

일관성 있는 스타일은 올바른 스타일보다 더 중요하다.

 

나쁜 이름에 주석을 달지 말고 대신 이름을 고쳐라.

좋은 코드 & 나쁜 코드 + 좋은 주석

 

주석처리

// 이런 제길, 이 리스트 안에 중복된 항목이 있으면 이건 복잡해지잖아

// 주의: 이 코드는 리스트 안에 있는 중복된 항목을 다루지 않는다. 그렇게 하는 것이 어렵기 때문이다.

 

if (a==b) {

// 첫번째 경우

} else {

// 두번째 경우

}

 

if (a!=b) {

// 두번째 경우

} else {

// 첫번째 경우

}

 

 

부정이 아닌 긍정을 다루어라

간단한 것을 먼저 처리하라

더 흥미롭고, 확실한 것을 먼저 다루어라

 

기본적으로 if/else를 이용하라. ?:를 이용하는 삼항 연산은 매우 간단할 때만 사용해야 한다.

 

가장 읽기 쉬운 코드는 아무것도 없는 코드다.

그 기능을 구현하려고 애쓰지 마라 - 그럴 필요가 없다.

프로그래밍은 창의력을 요구하는 분야다. 사진사, 작가, 영화감독 같은 사람은 모든 작업 결과를 보존하지 않는다.

 

요구사항에 질문을 던지고 질문을 잘게 나누어 분석하라

 

설계가 가지는 좋은 특징

특징	설계장점	테스트 장점
클래스들이 내부 상태를 거의 가지고 있지 않다.	소수의 내부 상태를 가지는 클래스는 이해하기 더 간단하고 쉽다	메소드를 테스트하기 전에 설정할 일이 거의 없고 감추어져 있는 상태가 별로 없기 때문에 테스트 작성에 수월하다.
클래스/함수가 한 번에 하나의 일만 수행한다.	더 작고 간단한 컴포넌트를 더 잘 모듈화되어 있고, 시스템이 서로 더 멀리 떨어져 있다.	더 적은 테스트 코드가 요구된다.
클래스가 다른 클래스에 의존하지 않고, 서로 상당히 떨어져 있다.	시스템이 병렬적으로 개발될 수 있다. 클래스가 쉽게 수정될 수 있고, 혹은 시스템의 나머지 부분에 영향을 주지 않으면서제거될 수도 있다.	각 클래스가 독립적으로 테스트 된다. (여러 클래스를 동시에 테스트 할 때에 비해서 훨씬 쉽다)
함수들이 간단하고 잘 정의된 인터페이스를 가지고 있다.	프로그래머가 인터페이스를 쉽게 배울 수 있어 해당 인터페이스는 재사용될 가능성이 더 높다.	테스트 대상이 잘 정의되어 있다. 간단한 인터페이스는 테스트를 위해서 더 적은 일을 요구한다.

 

 

get 이라는 단어는 보편적으로 가벼운 접근자라는 의미를 내포한다.

 

count() 대신 사용할수 있을 만한 이름

increment()

observe()

record()

add()

 

읽기 쉬운 100줄의 코드는 읽기 어려운 50줄의 코드에 비해서 훨씬 낫다.