TIL (Today I Learned)

2022.02.20

오늘 읽은 범위

2장. 의미있는 이름

책에서 기억하고 싶은 내용을 써보세요.

• 이름:

  변수(혹은 함수나 클래스)의 존재 이유는? 수행 기능은? 사용방법은? 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다. (P.22)

• 프로그래머는 코드에 그릇된 단서를 남겨서는 안된다. 그릇된 단서는 코드의 의미를 흐린다. 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안된다. (P.24)

  유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그릇된 정보다. (P.25)

• 컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다. 이름이달라야 한다면 의미도 달라져야 한다. (P.26)

• 독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환

  해야 한다면 그 변수이름은 바람직하지 못하다.

  이는 일반적으로 문제영역이나 해법영역에서 사용하지 않는 이름을 선택했기 때문에 생기는 문제다. (P.31)

• 똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이점 하나만 들자면 전문가 프로그래머는명료함이 최고라는 사실을 이해한다. (P.31)

• 추상적인 개념 하나에 단어하나를 선택해 이를 고수한다. (P.33)

• 한단어를 두가지 목적으로 사용하지 마라. 다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다. (P.34)

• 프로그래머는 크드를 최대한 이해하기쉽게 짜야한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다. (P.34)

• 적절한 '프로그래머 용어'가 없다면 문제 영역에서 이름을 가져온다. 그러면 코드를 보수하는 프로그래머가 분야 전문가에게 의미를 물어 파악할 수 있다. (P.35)

• 우수한 프로그래머와 설계자라면 해법 영역과 문제영역을 구분할 줄 알아야 한다. 문제영역 개념과 관련이 깊은 코드라면 문제영역에서 이름을 가져와야 한다. (P.35)

• 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.(p.35)

• 일반적으로 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. (P.37)

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 언제나 작명은 어려웠다. 어떻게 무엇을 작성해야할지 몰라 대충 입력해버린게 수두룩하다. 수정으로 하려해도 뭐가 뭔지 몰라 하나하나 체크하면서 진행해 시간은 더 오래 걸렸다.

• 이제 의미 있고 설명 가능한 단어를 조합해 따로 해석하는데 오래 걸리지 않는 이름을 작성해야하겠다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

헝가리안 표기법

• 데이터 타입을 변수명에서 바로 추정할 수 있다.

• IDE가 없을 때 작업하는 경우 (특히 vi나 emacs로 터미널에서 작업할 때) 여러모로 유리해진다.

• 같은 의미를 가지는 서로 다른 타입의 변수가 있을 때 이름 충돌을 방지할 수 있다.

• 아이러니하게도, 코드를 단번에 파악하기 힘들어진다.

• 변수나 함수 인자의 이름을 기억하기가 힘들다.

• 데이터 타입이 바뀌면 변수 또는 함수 인자의 이름을 바꿔야 한다. 리팩토링을 지원하는 IDE가 없으면 지옥도가 펼쳐질 것이다. 특히 PHP나 JavaScript, Python, Ruby 같은 동적 타입 언어와의 궁합은 최악.

• C/C++일 경우 언어 명세에서 데이터 타입의 크기를 강제하지 않은 바람에 시스템 아키텍처에 따라 데이터 타입의 크기가 다르다는 무시 못할 문제가 있다.[5] 예를 들어 w는 16비트일까? 32비트일까? 64비트일까?

• 같은 의미를 가지는 서로 다른 타입의 변수가 있을 때 이것들을 왜 선언했는지를 잊어버렸을 경우, 코드를 이해하기가 어려워진다.