DAY04

  • 오늘 읽은 범위 : 의미 있는 이름 ~p31 인코딩을 피하라까지

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

  • 의도를 분명히 밝혀라
    • 변수나 함수, 그리고 클래스 이름은 각각의 존재 이유, 수행기능, 사용방법에 대한 질문을 모두 답변해야 한다
    • 따로 주석으로 설명이 필요하다면 의도를 분명히 드러내지 못했다는 말이다
        int d;    // 경과시간(단위: 날짜)
      
    • 위 변수에선 아무 의미도 드러나지 않는다
        int elapsedTimeInDays;
      
    • 위처럼 의도가 드러나는 이름을 사용하라 - 코드 이해와 변경이 쉬워진다
    • 코드를 단순하게 짠다고 하더라도 함축성이 높으면 코드 맥락이 코드 자체에 명시적으로 드러나지 않는다1
      • 각 개념에 이름만 붙여도 코드가 상당히 나아진다2
    • 단순히 이름만 고친다 하더라도 좋은 이름을 붙힌다면 그 함수가 어떤일을 하는지 알기 훨씬 쉬워진다
  • 그릇된 정보를 피하라
    • 프로그래머는 코드에 그릇된 단서를 남겨서는 안된다.
      • 여러 계정을 묶을 때 실제로 해당 객체가 List 클래스가 아니라면 List를 사용해서는 안된다.
        • -Group 또는 해당 단어의 복수형을 쓰도록 하자
    • 서로 흡사한 이름을 사용하지 않도록 주의한다.
      • XYZControllerForEfficientHandlingOfStringsXYZControllerForEfficientStorageOfStrings -차이를 알아채기 힘들다-
    • 유사한 개념은 유사한 표기법을 사용해라-일관성이 떨어지는 표기법은 그릇된 정보다-
    • 이름으로 그릇된 정보를 제공하는 끔찍한 예: 소문자L(숫자 1처럼 보임)과 대문자O(숫자 0처럼 보임)
  • 의미 있게 구분하라
    • 컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으킨다.
      • 컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다 -이름이 달라야 한다면 의미도 달라져야 한다-
    • 읽는 사람이 차이를 알도록 이름을 지어라
  • 발음하기 쉬운 이름을 사용하라
    • 형편없이 발음되는 이름을 피하라 -genymdhms -> generationTimeStamp
  • 검색하기 쉬운 이름을 사용하라
    • 문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다.
      • e라는 문자 하나로 이름을 쓰지 말자
      • 간단한 메서드에서 로컬변수정도는 한개문자로 사용하여도 무방하다-이름길이는 범위 크기에 비례해야 한다.-
      • 변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.
      • 이름을 의미 있게 지으면 코드가 길어지나, 의미 있게 그리고 검색하기 쉽게 지은 이름이 훨씬 이익이 크다
  • 인코딩을 피하라
    • 유형이나 범위정보까지 이름에 포함시킬 필요는 없다.
    • 헝가리식 표기법
      • 이름길이가 제한되던 시절에 어쩔수 없이 위반했던 규칙이다. -오히려 헝가리식 표기법이나 기타 인코딩 방식이 방해가 될 뿐이다!
    • 멤버변수 접두어
      • m~이라는 접두어를 굳이 붙일 필요가 없다.-클래스와 함수는 접두어가 필요없을 정도로 작아야 한다!
      • 사람들은 접두/미어를 무시하고 이름을 해독하는 방식을 재빨리 익힌다-접두어는 구닥다리 코드!
    • 인터페이스 클래스와 구현 클래스
      • 인터페이스 자체에 I~로 시작하는 이름을 붙히기보다 구현 클래스의 접미어로 ~Imp를 사용하자-과도한 정보이다

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

  1. 개발자는 이름하나를 짓는데 굉장히 많은 시간을 쏟습니다. 어떻게 해야 지금 정의하려는 이 변수, 함수, 그리고 클래스명을 내가 의도하는 바를 명확하게 표현할 수 있을까 항시 고민해야하기 때문입니다. 이 챕터에서는 개발자들의 그러한 가려움증을 시원하게 긁어주는 가이드라인을 제시해주었습니다. 당연히 매우 많은 연습이 필요하겠지만 개발자로써 명명할 때 피해야 할 규칙들, 그리고 꼭 지키면 정말 좋을 규칙들이 많았다고 생각합니다

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

  • -
  1. p22~23 public List<int[]> getThem()의 예제 

  2. p23~24 public List<int[] getFlaggedCells()의 예제