210406 TIL

4/06

Today I Learn

• 백준 그래프의 표현
• 클린코드 2장, 자바의신 1장

오늘의 이야기

• 그동안 TIL을 안 썼던 이유.. 매일 하는 건 어차피 블로그에 포스팅하고 있고 TIL이 그냥 일기가 되고 있는 것 같아서 좀 회의감이 들었다. TIL이어도 내가 나중에 보고 배울 수 있는 내용을 포스팅 하고 싶었음. 그래서 배울 수 있는 내용이지만 따로 포스팅하긴 아쉬운 것들을 TIL에 써보는 건 어떨까? 싶었다.
  프로젝트 진행하며 배운 걸 쓰는 것도 좋아보이던데 아직 내가 하고픈 프로젝트 만들기엔 덜 배워서^^ㅠㅠ…부지런히 배워야지. 무튼 그래서 생각한 건 그 날 읽은 책을 정리하는 것.

• 오늘은 그 중 클린코드 2장을 정리해보려 한다. 2장은 변수/클래스/함수의 이름을 짓는 법에 대해 다루고 있다. 프로젝트 진행하면서 너무 긴 변수는 쓰기 힘들다고(…) 변수명 대충 지었었는데 보면서 반성했다.. 자동완성기능은 괜히 있는게 아니다!ㅠㅠ 책이 딱딱하지 않고 위트있게 적혀있어섴ㅋㅋㅋㅋ보면서 빵터지기도 했다. “흠, 여기 비 씨 알 3 씨 엔 티에 피 에스 지 큐 int가 있군요. 보입니까?” 이거 너무 웃겼음

• 쭉 다 읽고나서 소감은… 어렵다! 예제만 봐선 아아~ 그렇구나 하는데 실제 프로젝트에서 사용할 땐 변수명 짓느라 한세월 갈 것 같은 기분ㅋㅋ 네이밍센스가 중요하구나. 플젝으로 실제로 적용해야 변수명 짓는것도 늘듯하다..

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

1. 변수의 의도를 분명히 밝혀라
   코드는 읽는 사람이 쉽게 이해할 수 있어야 함. 따라서 변수의 이름을 명확하게 지어야 한다. 변수, 함수, 클래스 이름은 그것의 존재 이유는? 수행 기능은? 사용 방법은? 라는 질문에 답할 수 있는 이름이어야 함.

2. 그릇된 정보를 피하라

• 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안 됨.
• 계정을 담는 컨텐츠가 List도 아닌데 List로 짓는 건 지양. AccountList보다 accountGroup, Accounts로 명명해야 함.
• 서로 흡사한 이름을 사용하지 않아야 함. ex) XYZControllerForEfficientHandlingOfStrings 와 XYZControllerForEfficientStorageOfStrings
• 유사한 개념은 유사한 표기법 사용.

1. 의미있게 구분하라

• 연속된 숫자를 덧붙이거나 불용어(noise word)추가하는 방식은 x, 이름이 다르면 의미도 달라져야 한다.
• 불용어는 중복을 의미함. NameString, Name / Customer, CustomerObject 둘의 차이를 구분하기 힘들다.

1. 발음하기 쉬운 이름을 사용

2. 검색하기 쉬운 이름을 사용

• 문자 하나를 사용하는 이름, 상수는 쉽게 눈에 띄지 않는다. ex) 7, e
• 이름 길이는 범위 크기에 비례해야 함(저자는 간단한 메서드에서 로컬 변수만! 한 문자를 사용한다고 함). 여러 곳에서 사용된다면 검색하기 쉬운 이름이어야 한다.

1. 인코딩을 피하라

• 이 부분은 옛 C 개발자에게 더 와닿는 얘기일듯 하다. 헝가리식 표기법이나 기타 인코딩 방식으로 코딩 해본적이 없는 나는 그저 신기할뿐…
• 멤버를 표기하기 위해 m_ 같은 접두어를 붙이지 말란 소리. 인터페이스도 인터페이스임을 나타내는 접두어(I)를 붙이지 않는게 좋다함.

1. 자신의 기억력을 자랑하지 마라

• 루프 범위가 작고 다른 이름과 충돌하지 않을 땐 i,j,k 괜찮음(l은 I랑 헷갈리니까 금물). 그 외에는 적절치 않다.

1. 클래스 이름은 명사나 명사구로, 메서드 이름은 동사나 동사구로

• 클래스 : Customer, WikiPage, Account, AccountParser 좋은 예. Manager, Processor, Data, Info 같은 단어는 피하기. 동사는 사용하지 않는다. 의문점 : manager나 processor는 다른 데서도 일반적으로 쓰일 수 있어서 그런가??..
• 메서드 : postPayment, deletePage, save 좋은 예.
• 생성자를 오버로드 할 때는 정적 팩토리 메서드 사용. 인수를 설명하는 이름을 사용하자.

  Complex fulcrumPoint = Complex.FromRealNumber(23.0); //아래보다 good
  Complex fulcrumPoint = new Complex(23.0);
  

1. 기발한 이름은 피하라
2. 한 개념에 한 단어를 사용하라

• 똑같은 메서드를 클래스마다 fetch, retrive, get으로 제각각 부르면 혼란스럽다. 일관성 있는 어휘를 사용하자.

1. 말장난을 하지 마라

• 한 단어를 두 가지 목적으로 사용하지 마라.
• 기존값 + 기존값 = 새로운값에 add썼는데 집합에 값을 추가하는 메서드도 add 쓰면 안 된다. 차라리 insert, append를 붙이자.

1. 해법 영역에서 가져온 이름을 사용하라

• 기술 개념엔 기술 이름이 적합. 코드 읽는 사람은 프로그래머다. ex) JobQuene, AccountVisitor(Visitor패턴)

1. 문제 영역에서 가져온 이름을 사용하라

• 적절한 프로그래머 용어가 없다면 문제 영역에서 이름을 가져온다. 해법 영역과 문제 영역을 구분할 줄 알아야 하는데, 문제 영역 개념과 관련 깊은 코드면 문제 영역에서 이름을 가져와야 한다. 문제 영역이 뭔지 잘 안 와닿는다. 예시가 없으니 뭔말인지 모르겠음ㅠ

1. 의미 있는 맥락을 추가하라

• 의미가 분명한 단어는 많지 않으니 맥락을 부여하라는 것.
• state라는 변수만 있다면 주소 일부라는 걸 알기 어렵다. addrFirstName, addrLastName, addrState 이렇게 맥락을 추가. Address 클래스 생성하면 더 좋음. 여기에 있는 예시코드 너무 잘 되있다

1. 불필요한 맥락을 없애라

• 고급 휘발유 충전소(Gas Station Deluxe) 애플리케이션을 짠다고 클래스 이름 시작을 GSD로 맞추는 건 바람직하지 않다.
• 의미가 분명한 경우에 한해서 짧은 이름이 긴 이름보다 좋다.
• accountAddress, customerAddress는 Address 클래스 인스턴스 명으로 좋으나 클래스명으론 적합하지 않음. Address는 클래스 이름으로 좋음. 포트 주소, MAC 주소, 웹 주소를 구분해야 하면 PostalAddress, MAC, URI 이름도 좋음.