Books/읽기 좋은 코드가 좋은 코드다

2. 이름에 정보를 담아내라

개발하는 사막여우 2021. 11. 30. 18:57
반응형

이 글은 읽기 좋은 코드가 좋은 코드다(더스틴 보즈웰, 트레버 파우커 지음 / 임백준 옮김 / 한빛미디어) 를 읽고 내용을 정리한 글입니다.

<<변수의 이름은 작은 설명문이다!>>

 

1. 특정한 단어 고르기: 구체적인 단어를 통해 무의미한 단어 피하기

-> 유의어 색인집을 찾는 것, 동료에게 물어보는 것이 좋다.

 

2. tmp나 retval같은 보편적인 이름 피하기: 개체의 값이나 목적을 정확하게 설명한 이름을 사용

-> 변수의 이름은 변수의 목적이나 담고 있는 값을 설명해주어야 한다.

-> i,j,k라는 뻔한 루프 반복자보다 club_i, members_i, users_i 같은 의미를 담은 반복자가 낫다.

-> tmp, it, retval을 사용할 경우, 꼭 그렇게 하는 이유가 있어야 한다.

-> tmp: 대상이 용도가 오직 임시적으로 존재하는 것만일 때 사용한다.

 

3. 추상적인 이름보다는 구체적인 이름 사용: 구체적인 방식으로 이름을 묘사

-> DISALLOW_EVIL_CONSTRUCTOR(추상적) < DISALLOW_COPY_AND_ASSIGN(구체적)

-> 두 가지 동작(값, 기능)을 포괄하는 이름을 사용할 바에는, 개체 자체를 두 가지 동작으로 나눈다.

 

4. 추가적인 정보를 이름에 추가하기: 변수의 의미를 제대로 이해하는 것이 중요하다면 그 의미 정보를 변수 이름에 포함

-> 사용자가 반드시 알아야할 변수와 관련된 중요한 정보를 추가적인 '단어'로 만들 것

    (ex: id -> hex_id)

-> 변수가 측정치(시간의 양 or 바이트 수)를 담고 있다면, 변수명에 단위를 포함시키는 것이 좋다.

    ex: (delay -> delay_secs), (size -> size_mb), (limit -> max_kbps)

-> 위험한 요소나 확인해야할 내용이 있다면 위 방법을 마찬가지로 사용

    ex: (암호화가 필요한 password -> plaintext_password), (이스케이프 처리가 필요한 comment -> unescaped_comment), (utf-8로 변환된 html -> html_utf8)

 

5. 이름의 길이를 결정하기: 변수의 정확한 용도에 따라 판단

-> 좁은 범위(scope)에서는 짧은 이름이 괜찮다. 변수에 대한 정보를 한 눈에 볼 수 있기 때문.

-> 특정 프로젝트에 국한된 그들만의 약어/축약어는 Bad. 팀에 새로 합류한 사람이 의미하는 바를 이해할 수 있을지 고민한다.

-> 불필요한 단어는 제거한다.

    ex: (ConvertToString -> ToString), (DoServeLoop -> ServeLoop)

 

6. 이름 포맷팅을 통한 의미 전달: 밑줄과 대시를 이용한 포맷팅

-> JS의 경우, 생성자는 대문자+대문자(ex:DatePicker), 일반 함수는 소문자+대문자(pageHeight)

-> HTML/CSS의 경우 id는 밑줄('_'), class는 ('/')로 구분하면 편하다.

반응형