# 의도를 분명히 밝혀라
# 그릇된 정보를 피하라
# 의미 있게 구분하라
# 발음하기 쉬운 이름을 사용하라
# 검색하기 쉬운 이름을 사용하라
# 인코딩을 피하라
# 자신의 기억력을 자랑하지 마라
# 클래스 이름
# 메소드 이름
# 기발한 이름은 피하라
# 개념 하나에 단어 하나를 사용하라
# 말장난을 하지 마라
# 해법 영역에서 사용하는 이름을 사용하라
# 문제 영역과 관련 있는 이름을 사용하라
# 의미 있는 맥락을 추가하라
# 불필요한 맥락을 없애라
별다른 내용은 없다. 의도가 불분명한(변수를 a, b, s 등으로 짓는) 변수 및 함수(foo(x))를 사용하지 말고, 발음하기 쉽고 검색하기 쉬운(setPoint(int x, inty)) 것, 그리고 자신의 기억력을 믿지 말것이며(코드가 몇 만라인이 넘어가는 자신이 작성한 메소드 혹은 함수를 기억하는가?) 자신만이 알아 보는 변수 및 말장난, 단어를 사용하지 말것.(hellobaby, suxxx 등?). 그리고 함수나 메소드를 사용할 때(일반적으로 IDE(통합 개발툴)을 사용한다 치고) 굳이 주석이 없더라도 메소드의 기능 및 역할을 알 수 있는 이름으로 작성. 메소드나 함수 작성시 불필요한 내용, 혹은 불필요한 정보가 담긴 이름을 사용하지 마라(accountAddres와 customerAddress는 클래스 인스턴스로 적합하지 않음. 보면 바로 알 수 있는 이름으로 작성하라. 예를 들면 MAC, PortAddress, URI 같은 이름. 물론 그 의미가 다른 의미와 중첩되면 안된다)
프로그래머는 대부분의 시간을 자신의 코드 혹은 타인의 코드를 읽으며 프로젝트 혹은 작업을 진행하게 된다. 이런 작업을 할때, 보다 빠르게 이해하고 진행하기 위해서 보다 의미 있는 이름을 작성해야 된다고 적혀 있다. 물론 옳은 말이며 대부분의 시간이 오류나 잘못된 구문을 찾기 위해 코드 리뷰는 ... 거의 필수다.(설계가 퍼팩트 하지 않는 이상)
해당 챕터를 보면서 다시금 작명의 중요성을 깨닳게 된다. 작명 ... 그러기 위해선 많은 코드를 접해 보아야 하며 많은 이름을 만들어 보며, 그리고 스스로 반성하는 시간을 가져야 되겠다.
※ 위의 내용은 "Clean Code" 내용의 일부를 발췌했음을 밝힙니다.