[클린코드] 2장 의미있는 이름

의미있는 이름은 중요하다고 생각한다. 프로젝트가 커지면 커질 수록, 협업 인원이 늘어날 수록 더 중요해지는 것같다.

클린 코드에서는 이름에 대한 몇 가지 원칙을 제시해주고있다.

 

'의도를 밝혀라'

즉, 코드를 보았을 때 코드 맥락에 관한 정보를 제공할 수 있도록 하기위해서는 이름에 의도가 드러나야한다.(코드의 단순성 < 코드의 함축성)

가령, 보드판 게임에 관한 코드를 작성할 때

List<int[]> 보다는 List<Cell>,

그리고 if(cell[STATUS] == FLAGGED)보다는 if(cell.isFlagged()) 라는 명시적인 함수가 더 적절하다.

 

'그릇된 정보를 피하라'

프로그래머에게 혼동을 줄 수 있는 이름들도 '그릇된 정보'에 해당하는 것같다. 명령을 담당하는 클래스를 Manager라고 했다가, 다른 쪽에서는 Command라고 했다가.. 이런 식으로 일관성이 떨어지는 코드들도 그릇된 정보이고 피해야할 명명법이다. 그리고 l과 1, o와 0처럼 모양이 헷갈리는 요소들 또한 직관성을 해치는 코드이기 때문에 지양해야한다.

 

'의미있게 구분하라'

a1, a2는 이름만 봤을 때 둘은 아무런 의미가 없다. 또한 getData()와 getInfo() 또한 구분이 명확하지 않다. 의미있는 구분이 필요하다.

 

'발음 쉬운 이름'

말 그대로, 누구나 딱 이렇게 밖에 발음할 수 밖에 없도록 발음이 쉬운 이름을 택하라. 어쩌면 이런 이름들은 줄임표현들을 빈번하게 여러번 사용해서 나타나는 문제일 수도 있다고 생각한다. 그래서 물론 짧은 이름이 제일 좋다고 생각하지만 개인적으로는 길어지더라도 확실하게 이름이 드러나는 것을 좋아하는 편이다. addr보다 address라고 확실하게 표기하는 편이다. 

 

'인코딩을 피하라'

변수명에 타입을 넣는 등 부가적인 정보들이 들어가게되면 꼭 필요한 정보들이 묻히기 쉽다. 그래서 실제 container가 List 타입이더라도 이름에 List를 넣지 말라는 이유가 여기에 있는 것같다. AccountList 보다는 Account로 표기하는 것이 적절하다. 그러나 인터페이스와 구현클래스를 명명할 때는 인코딩으로 구분해주는 것도 좋다. 단, 접두어에 인터페이스임이 드러나기보다는 Account와 Accountlmpl처럼 구분을 해주는 것이 좋다.

 

'자신의 기억력을 자랑하지마라' '기발한 이름을 만들지 마라'

사실 기억력이 안좋고 창의력이 떨어져서 쉽고 직관적인 이름을 지향하는 편이다. 자랑할 일은 없겠지만, 그래도 명심해두자.

 

'클래스와 메소드'

클래스는 명사나 명사구, 메소드는 동사와 동사구. 이건 클래스와 메소드라는 개념을 처음 배울 때 자연스럽게 습득하는 명명법이지만 기본을 무시하지 말자. 그리고 생성자 overload시에는 정적 팩토리 메소드를 사용하는 것이 좋다고 언급했는데, 정말 맞는 것같다. 생성자의 수가 2개 이상이 되면, 팩토리 패턴을 사용하여 생성자를 만드는 것이 더 적절하다고 생각한다..! 클린코드는 정말 디자인 패턴과 공유하는 부분들이 많은 것같다.

 

'한 개념에 한 단어'

아까 '그릇된 정보를 피하라'에서 말했던 것과 비슷하다. 가령 Controller 계층의 class들은 모두 뒤에 Manager가 오게끔! 혹은 Controller가 오게끔! 같은 @Controller 클래스인데 하나는 UserController, 다른 하나는 UserManager가 되어서는 안된다는 말이다.

 

'말장난을 하지 마라'

기존에 값을 더하는 메소드 이름이 add()이고 일관성을 지키기 위해서 새로운 정보를 추가할 때 addUser() 이런 식으로 명명할 필요가 없다. 이런 경우에는 Insert나 append가 더 적절하다. '같은 맥락'이 아니라면 일관성을 지킬 필요가 없다.

 

'해법영역/문제영역에서 가져온 이름 사용'

코드를 읽을 사람은 프로그래머이기 때문에 프로그래머가 이해할 수 있는 선에서 전문 용어들을 사용하는 것도 좋다. 가령 아까 메소드 오버로딩을 위해 Factory 패턴을 사용해야한다고하면, UserFactory 이런 식으로 명명해줄 수도 있다. 만약 적절한 프로그래머 용어가 없을 시에는 문제영역(Domain)에서 유의미한 이름을 가지고 오는 것도 좋다. 특히, 해당 메소드가 문제영역에 관련된 코드라면 굳굳.

그리고 'JobQueue'를 모르는 프로그래머가 있을까? 라는 말에.. 얼어붙은 1인... 저 몰라효...😂 ㅇ...아직 프로그래머가 아니니 괜찮겠지.. 찾아보니까 job queue is a location where jobs are held before being sent to the CPU [참조] 라고한다 메모메모

 

'의미있는 맥락을 추가하라'

의미있는 이름이라 할지라도 가끔은 맥락을 알기 힘들 때가 있다.

firstName, lastName, street, state, city 등과 같은 변수명이 들어있는 클래스를 보면 대강 주소에 관한 클래스라는 것을, 맥락을 알 수가 있다. 하지만 state 처럼 하나의 변수만을 사용할 경우에는 맥락을 알기 힘든 경우가 많다. 그럴 때는 변수 명에 맥락을 언급해주면 조금 더 이해하기 쉬운 코드가 된다. 가령 addr라는 접두어를 넣어, addrFirstName, addrLastName, addrState, .. 로 표기하면 Address와 관련된 변수들이라는 것을 쉽게 확인할 수 있다.