Day 4
🔖 오늘 읽은 범위: 2장 의미 있는 이름
😃 책에서 기억하고 싶은 내용을 써보세요.
의도를 분명히 밝혀라
주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.
ex) int d (x) int fileAgeInDays (o)
그릇된 정보를 피하라
- hp,aix,sco 는 변수 이름으로 적합하지 않다. 유닉스 플랫폼이나 유닉스 변종을 가리키는 이름이기 때문.
- 계정을 담는 컨테이너가 실제 List 가 아니라면 ~List 라고 이름짓지 않는다. 단순히 ~Group,~Accounts 라고 이름짓자.
- 서로 흡사한 이름을 사용하지 않도록 주의한다.
- 유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다.
의미있게 구분하라
- 불용어를 추가하는 방식은 적절하지 못하다. ... a 나 the 와 같은 접두어를 사용하지 말라는 소리가 아니다. 의미가 분명히 다르다면 사용해도 무방하다. ... Info 나 Data 는 a,an,the 와 마찬가지로 의미가 불분명한 불용어이다.
- 연속적인 숫자를 덧붙인 이름(a1,a2,...,aN)은 의도적인 이름과 정반대다. 저자의 의도가 드러나지 않는다.
발음하기 쉬운 이름을 사용해라
검색하기 쉬운 이름을 사용하라
- 이름 길이는 범위 크기에 비례해야 한다. 변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.
- 이름을 의미있게 지으면 함수가 길어진다. 하지만 WORK_DAYS_PER_WEEK 를 찾기가 얼마나 찾기가 쉬운지 생각해보라.
인코딩을 피하라
- 객체는 강한 타입strongly-typed 이며, IDE 는 코드를 컴파일하지 않고도 타입 오류를 감지할 정도로 발전했다. 따라서 이젠 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 될 뿐이다.
- 결국은 접두어는 옛날에 작성한 구닥다리 코드라는 징표가 되버린다.
- 인터페이스 클래스에 구현은 구체 클래스에서 한다면 이름은 어떻게 짓는게 좋을까? ex) IShapeFactory 와 ShapeFactory? 개인적으로 인터페이스 이름은 접두어를 붙이지 않는 편이 좋다고 생각한다.
🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
변수명 길어질 때마다 니꼬쌤이 원망스러웠는데 왜 그런지 이유를 알게된 장이었다. 좋은 코드는 이런 디테일도 신경쓰는구나, 생각했다. 변수명에 접두어를 붙이는 트렌드는 TS 와 IDE 의 발전으로 점점 사라져가는 추세라는 것도 알게되었다.
🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
-
컴파일러, Compiler: 프로그래밍 언어를 Runtime 이전에 기계어(이진법)으로 해석하는 작업 방식이다.이때 원래의 소스를 원시 코드, 바뀐 코드를 목적 코드(Object Code) 라 한다.
-
인터프리터, Interpreter : 런타임 이전에 기계어로 프로그래밍 언어를 변환하는 컴파일 방식과 다르게, 런타임 이후에 Row 단위로 해석(Interpret) 하며 프로그램을 구동시키는 방식이다
-
불용어, noise word: 인터넷 검색 시 검색 용어로 사용하지 않는 단어. 관사, 전치사, 조사, 접속사, 접두사, 접미사 등은 검색 색인 단어로 의미가 없는 단어이다.
-
인코딩, encoding: 컴퓨터를 이용해 영상 · 이미지 · 소리 데이터를 생성할 때 데이터의 양을 줄이기 위해 데이터를 코드화하고 압축하는 것
-
헝가리식 표기법: 찰스 시모니(Charles Simonyi) 가 마이크로소프트의 개발 책임자로 있을 때 제안했으며, 80년대 당시에는 IDE라는게 다들 부실했기 때문에 이 규칙이 엄청난 센세이션을 불러 일으켰다. 접두어(문자 또는 숫자 하나) 를 이용해 데이터 타입을 구분했다. [자세한 규칙은 여길 참조] 헝가리안 표기법이라는 명칭은 제안자인 찰스 시모니가 헝가리인이라서 붙은 것이다.
출처: https://jins-dev.tistory.com/222 [Jins' Dev Inside], 위키피디아, 나무위키
소감 3줄 요약
- 니꼬쌤 변수명 길어질 때 원망해서 죄송했어요.
- 좋은 변수 이름은 길어질 수 도 있지만, 의미를 부여하고 의도를 확실히하며, 검색을 쉽게 한다.
- 접두어는 사라져가는 추세이다.
