변수/메서드 네이밍 TIP!

프로그래머가 가장 힘들어하는 일은?

개발자라면 위의 짤을 한번씩은 본 적이 있을 것이다. 이름 짓기란 제일 힘들고 많이 시간을 소요하는 의도치 않은 부분이기도 하다.

본인은 실제로 현업에서 함께 사용하는 식별자의 네이밍에 대해 3시간 이상도 논의해본 적이 있다.

 

 

대체 네이밍은 왜 이렇게 시간을 잡아먹고 이렇게 중요한 것일까?

해당 내용은 Udemy의 '개발자 영어' 강의를 기반으로 작성되었습니다.

 

식별자 이름

• 식별자 종류 : 타입, 변수, 메서드, 함수, 모듈, 라이브러리, 네임스페이스 등이 존재한다.
• 이름의 중요성
  • 이름은 코드 기반의 상당한 부분을 차지
  • 코드 리뷰 시 지적되는 사항의 약 25%가 식별자 이름
  • 이름은 표식이자 이해에 도움을 주는 일종의 문서 역할을 수행
  • 프로그램 개발 초기에 만들어진 식별자의 품질이 계속 유지될 가능성이 큼
    • 동일한 코드 기반 내에서 명명 관행은 일정하게 유지됨
  • 문법적으로 비슷한 이름은 묶어 생각하게 되므로, 일관성 있는 이름을 지어 처리 과정에서의 부하를 낮춘다.
  • 변수 이름은 코드 도메인, 프로그래밍 방법 자체, 변수에 담긴 이미 알고 있는 정보 등의 내용을 포함한다.
• 주의할 점
  • 비정상적인 대문자 사용 자제 (ex. stArtacTivity)
  • 연속된 underscore 사용 자제 (ex. start__activity)
  • 사전에 등재되지 않은 단어 사용 자제 (ex. start_activ)
  • 너무 많은 단어 사용 자제 (ex. start_activity_by_using_navigation_through_fragment)
  • 짧은 이름 사용 자제 (ex. S)
  • 열거형 식별자에서 임의의 순서 선언 자제 (ex. TierList = {BRONZE, PLATINUM, IRON, SILBER, DIAMOND, GOLD, CHALLENGER, MASTER, GRANDMASTER…})
  • 식별자 인코딩 자제 (ex. intent_start_activity, int_count_num)
  • 명명법 규약 지키기 (ex. Start_Activity)
    
    

더 나은 이름을 짓는 법

• 페이텔슨의 3단계 모델 (ex. 메시지를 보낸다.)
  • 이름에 포함할 개념을 선택한다.
    • 객체가 어떤 정보를 보유하며 무엇을 위해 사용되는지, 제공해야하는 정보는 무엇인지 포함시킬 의도를 정한다.
  • 각 개념을 나타낼 단어를 선택한다. (ex. 메시지 → Message/Request…, 보낸다 → Send, Post...)
    • 개념을 나타낼 단어를 선택하는데, 중의적 이거나 미묘한 차이가 있지는 않는지 논의가 생길 수 있다.
  • 단어를 사용해 이름을 구성한다. (ex. sendMessage)
    • 선택된 단어를 사용해 이름을 구성할 때, 영어의 특성에 맞춘다. (어순 및 전치사 등 ..)
• 기본 원칙
  • 서술적인 이름을 사용한다.
  • 적절한 추상화 수준에서 이름을 정한다.
    • 구현 내용이 직접적으로 드러나는 이름은 피하며 작업 대상 클래스나 함수가 위치하는 추상화 수준을 반영하는 이름을 선택한다.
  • 표준 명명법을 활용한다.
    • 만일 SingleTon 패턴을 사용한다면 해당 단어를 사용하거나 클래스에서 구현부를 분리할 경우 Impl 등을 사용한다.
  • 명확한 이름을 사용한다.
    • 목적을 명확히 밝히는 이름을 선택한다.
  • 인코딩을 피한다.
    • 이름에 타입 정보와 범위 정보를 넣어서는 안된다. (ex. personLocationString…)
  • 이름으로 효과를 설명한다.
    • 하는 일을 모두 기술하는 이름을 지향하자. 부수적인 효과 이더라도 숨기지 않는다. (ex. createOrReturnInstance…)
• 작명 규칙
  • 이름에 정보를 담는다.
    • 단어의 선택에 신중을 기한다.
      • 예시
        • stop() 를 대신한다.
          • 다시 되돌릴 수 없다면 kill(), 되돌릴 수 있으면 pause()가 더 좋은 이름
        • send() 를 대신한다.
          • 편지/메시지를 전송할 경우 dispatch(), 최적의 경로를 선택해 보낼 경우 route(), 어떤 사항을 공지할 경우 announce()가 더 좋은 이름이다.
        • find() 를 대신한다.
          • 데이터베이스에서 검색할 경우 search(), 정보 등을 추론할 경우 extract(), 위치를 찾을 경우 locate()가 더 좋은 이름이다.
        • start() 를 대신한다.
          • 프로그램을 시작할 경우 launch(), 프로세스를 생성할 경우 create()가 더 좋은 이름이다.
        • make() 를 대신한다.
          • 소스 코드에서 object 파일을 생성하는 경우 build(), 비즈니스에 필요한 결과물을 생성하는 경우 generate(), 존재하는 구성요소로 뭔가를 조립할 경우 compose()가 더 좋은 이름이다.
    • 보편적인 이름은 피한다.
      • ex. tmp, ext, retval, gap, spec 등 검색이 어렵고 이해가 단번에 되지 않을 수 있다.
    • 추상적인 이름 대신 구체적인 이름을 사용한다.
    • 추가적인 정보 덧붙이기
      • 접두사/접미사 등을 사용한다. (ex. 평문 암호인 경우 password → plaintext_password…)
    • 눈에 띄게 만들기
      • camelCase: 첫 단어를 제외한 나머지 단어의 첫글자를 대문자로 만든다.
      • snake_case: 단어와 단어 사이에 밑줄을 사용한다.
      • PascalCase: 단어의 첫글자를 대문자로 만든다.
  • 클래스, 메서드 이름
    • 클래스 이름은 명사구가 적합하다.
      • (ex. Customer, Employee, WikiPage, Account …)
    • 메서드 이름은 동사나 동사구가 적합하다.
      • 접근자 앞에는 get을, 변경자 앞에는 set을, 조건자 앞에는 is를 붙인다.
    • 한 개념에 한 단어만 사용한다.
      • 같은 메서드를 클래스마다 get(), fetch(), bring(), retrieve 등으로 부르면 혼란이 발생한다.
    • 한 단어를 두가지 목적으로 사용하지 않는다.
      • 같은 이름을 다른 역할을 수행하는 메서드로 오버로딩해 사용하지 않는다.

 

작명의 도움을 주는 사이트

이렇게 법칙, 권고 사항을 아무리 봐도 참고할 것이 없으면 감이 잡히지 않을 것이다. 따라서 구체적인 작명에 대한 감은 기존 코드나 오픈 소스 코드를 많이 읽어보면 도움이 될 것이다.

또한, 아래의 사이트는 뜻을 적으면 보편적인 작명을 도와주므로 해당 사이트도 도움이 될 것이다.

• https://www.curioustore.com/#!/