요약하면서 읽지 않으면 정말 페이지를 넘기자마자 까먹을 것 같은 내용들이라..
의도를 분명히 밝혀라.
이 변수(혹은 함수, 클래스)의 존재 이유, 수행하는 기능, 사용 방법을 다 알 수 있는 이름을 지어야 한다. 주석 없이 이름만으로 이를 다 알 수 있어야 한다.
코드의 맥락이 코드 자체에서 다 드러나야 한다. 이 코드를 읽는 주체가 코드에 대한 정보를 아예 모른다고 가정하고, 이를 다 알 수 있도록 명명하자.
그릇된 정보를 피하라.
여러 정보를 하나의 컨테이너에 담을 때, 이 컨테이너가 List가 아니라면 List라고 명명하지 않아야 한다. 이 또한 그릇된 정보를 제공하는 것이다.
ex. accountList 대신 accountGroup, accounts 로 나타내기.
정보를 일관성있게 나타내는 것도 중요하기 때문에 유사한 개념은 유사한 표기법을 사용해 나타내야 한다.
의미 있게 구분하라.
이름이 달라진다면 의미 또한 달라져야 한다. a1, a2, .. 와 같이 연속된 숫자를 덧붙인 이름은 아무런 의미를 가지고 있지 않기 때문에 지양해야 한다.
func copyChars(a1: [Character], a2: [Character]) {
var a1 = a1
var a2 = a2
for index in 0..<a1.count {
a2[index] = a1[index]
}
}a1, a2와 같은 이름 대신 source, destination을 사용합시다..
불용어를 추가한 이름 또한 아무런 정보도 제공하지 못한다. NameString과 Name이 있다고 가정해보자. Name에 String을 추가한다고 해서 의미가 달라지는가? 그렇지 않다. CustomerInfo와 Customer는? 역시나 읽는 사람이 아무런 차이를 알 지 못할 것이다. 읽는 사람이 차이를 알도록 명명하자!
발음하기 쉬운 이름을 사용하라.
코드를 읽는 것은 글을 읽는 것과 같다.
발음하기 어려운 이름은 읽는 것뿐만 아니라 이를 가지고 토론하기도 어렵게 만든다.
검색하기 쉬운 이름을 사용하라.
무슨 이름을 짓는데 검색할 것까지 생각하나? 싶겠지만 코드의 양이 많아지고 프로젝트의 규모가 커질 것을 생각하면 반드시 고려해야 할 사항이다.
e, i와 같은 짧은 이름의 변수는 검색하기 어렵다. 영어에서 많이 사용되는 문자이기 때문이다. 검색할 것을 고려하면 긴 이름이 짧은 이름보다 좋다.
이름의 길이는 범위 크기에 비례해야 한다. 물론 코드가 길어질 수는 있다. 하지만 검색하기 쉽고 이해하기 쉽다는 장점이 훨씬 크다.
인코딩을 피하라.
과거에는 이름의 길이를 제한된 언어를 사용했기 때문에 이름에 많은 정보를 함축해서 담았다. 멤버 변수에 접두어를 붙이기도 했다. 위에서 나타낸 것처럼, 어차피 이름에는 많은 정보를 담아야 하기 때문에 굳이 담지 않아도 될 정보는 빼도록 하자. 이제는 멤버 변수를 다른 색상으로 나타내 주는 IDE를 사용하고 있으니까.
자신의 기억력을 자랑하지 마라.
독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해서 이해해야 한다면, 이는 잘못된 이름인 것이다.
문자 하나만 사용하는 변수 이름은 문제가 있다. 물론 반복문에서 반복 횟수를 세는 i, j, k 정도는 괜찮다. 대신 반복하는 범위가 작고 다른 이름과 충돌하지 않을 때만 괜찮다. 반복 횟수 변수는 전통적으로 한 글자를 사용하기 때문이다.
그 외, 독자가 코드를 읽으며 실제 개념으로 변환해야 하는 그런 이름은 적절하지 않다.
클래스 이름
클래스, 객체 이름은 명사나 명사구가 적합하다. 동사는 사용하지 말자.
Customer, WikiPage, Account, AddressParser 등이 좋은 예이고, Manager, Processor, Data, Info와 같은 단어는 피해야 한다.
메소드 이름
메소드 이름은 동사나 동사구가 적합하다.
postPayment, deletePage, save 등이 좋은 예이다.
기발한 이름은 피하라.
재밌는 이름보다 명확한 이름을 선택하자. 또한 특정 문화에서만 사용하는 농담은 피하자.
의도를 분명하고 솔직하게 표현하는 것이 가장 중요하다.
변수 이름 기발하게 지어봤자 뭐하겠음.. 재밌어도 혼자 재밌지.. 나중에 읽어도 바로 이해할 수 있도록 짓자.
한 개념에 한 단어를 사용하라.
개념 하나에는 단어 하나를 선택해서 이를 쭉 사용하자. 예를 들어서, 똑같은 메소드인데 클래스마다 fetch, get 등으로 제각각 부르면 같은 개념이 맞는지 한 번 더 생각하게 될 것이다. 또한 어느 클래스에서 어느 이름을 썼는지 기억하기도 어려워진다.
마찬가지로, controller, manager, driver 등을 섞어서 사용하지도 말자. 어차피 유사한 역할을 하는 메소드라면 굳이 다른 이름을 쓸 필요도 없다.
말장난을 하지 마라.
한 단어를 두 가지 목적으로 사용하지 마라. 다른 개념에 같은 단어를 사용한다면 이는 말장난에 불과하다.
예를 들어서, 일관성을 지키기 위해 여러 클래스에 add라는 메소드를 생성했다면?
물론 매개변수와 리턴값이 의미하는 게 다 같으면 아무런 문제가 없다. 기존 값 두 개를 더해 새로운 값을 만드는 것이라고 가정해보자. add 메소드를 이러한 의미로 사용하다가, 갑자기 기존 컨테이너에 새 값을 추가하는 메소드에 add를 사용한다면?
어차피 이 작업도 무언가를 더하는 작업이기 때문에 add를 써도 되지 않느냐? 라고 묻는다면 이는 말장난인 것이다. 이럴 때는 insert, append 등을 사용하면 된다.
해법 영역에서 가져온 이름을 사용하라.
코드를 읽을 사람 또한 프로그래머이다. 그러므로 Queue, Tree 등의 기술 개념을 이름으로 사용해도 좋다.
어차피 프로그래머가 알고 있는 개념이기 때문에 굳이 다른 말로 바꾸어서 명명할 필요가 없다.
문제 영역에서 가져온 이름을 사용하라.
적절한 '프로그래머 용어'가 없다면 문제 영역에서 이름을 가져온다.
사실 문제 영역이 뭔지 모르겠고 검색해도 다 클린코드 요약밖에 없음 .. 쩝
의미 있는 맥락을 추가하라.
예를 들어서 firstName, lastName, houseNumber, state, city, zipCode 라는 변수들이 있다. 이를 쭉 읽어보면 state가 주소의 일부를 나타낸다는 것을 알 수 있다.
하지만 이런 맥락 없이 state라는 변수 하나만을 사용한다면? 주소를 나타낸다는 것을 알 수 있을까?
이럴 때는 addr라는 접두어를 추가해보자. addrFirstName, addrState라 쓰면 맥락이 좀 더 분명해진다.
물론 Address라는 클래스를 생성해 city, state 등을 프로퍼티로 가지면 더욱 좋다. Address라는 개념에 속한다는 사실을 더욱 직관적으로 알 수 있기 때문이다.
불필요한 맥락을 없애라.
Gas Station Deluxe라는 애플리케이션을 짠다고 가정해보자. 모든 클래스 이름을 GSD로 시작하는 것은 전혀 바람직하지 않다. G를 입력하고 자동완성을 누르면 모든 클래스가 나타날 것이다..
짧은 이름보다는 긴 이름이 낫다고 계속해서 말해왔다. 하지만 이는 의미가 분명한 경우에 한해서 말하는 것이다.
이름에 불필요한 맥락을 추가할 필요는 전혀~~ 없다.
