이번 주 클린 코드는 3, 4장이다

제 3장 함수

• 작게 만들어라!

  • 각 함수가 명백하게 하나의 이야기만 표현
  • if, while, else 문 등에 들어가는 블록은 한 줄 → 거기서 함수를 호출
  • 중첩 구조가 생길만큼 함수가 커지면 안됨 → 들여쓰기 수준은 1단이나 2단을 넘어서면 안됨

• 한 가지만 해라!

  • 함수는 한 가지를 해야 한다. 그 한가지를 잘 해야 한다. 그 한 가지만을 해야 한다.

• 함수당 추상화 수준은 하나로!

  • 내려가기 규칙
    • 위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 한 번에 한 단계씩 낮아짐

• Switch 문

  • switch 문은 작게 만들기 어렵다 → 진짜 케이스 하나씩 추가하다 어느새 100줄 되어있는 경험 해봄
  • switch 문을 추상 팩토리에 숨겨서 보여주지 않는 방법 → 추상화를 통한 객체지향 원칙 지키기? 근데 코드짜기 더 복잡해보인다

• 서술적인 이름을 사용하라!

  • 함수가 작고 단순할수록 서술적인 이름을 고르기도 쉬워진다.
  • 이름이 길어도 괜찮다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋다 → 저학년때는 무조건 짧은 변수명이나 함수명이 좋은 줄 알았는데 협업이나 개인 프로젝트를 진행하다보니 짧은것보다 긴 역할을 잘 나타내는 변수명/함수명의 중요성을 느꼈다..

• 함수 인수

  • 이상적인 인수 개수는 0개 → 1개 → 2개다
  • 3개 이상은 가능한 피하는 편이 좋다 → 확실히 변수 3개 되면 코드 보기가 싫어지는 경험을 했다
  • 4개 이상은 특별한 이유가 있어도 사용하지 않는게 좋음
  • 인수 객체
    • 객체를 생성해 인수를 줄이는 방법이 눈속임이라 여겨질지 모르지만 그렇지 않다! → 나는 DTO 사용할 때 이 방식을 쓴다

• 부수 효과를 일으키지 마라!

  • 많은 경우 시간적인 결합이나 순서 종속성을 초래함

• 명령과 조회를 분리하라!

  • 함수는 뭔가를 수행하거나 뭔가에 답하거나 둘 중 하나만 해야 한다.

  public boolean set(String attribute, String value)

  • 위의 함수는 value 값을 설정한 후 성공여부에 따라 boolean값을 반환한다

  if(attributeExists("username"){
      setAttribute("username", "unclebob"); 
  }

  • 이런식으로 명령과 조회를 분리해준다

• 오류 코드보다 예외를 사용하라!

  • 오류 코드 대신 예외를 사용하면 오류 처리 코드가 원래 코드에서 분리되므로 코드가 깔끔해진다
  • try/catch 블록을 상위함수로 뽑아 내부 로에서 발생하는 예외에 대한 처리를 깔끔하게 해준다 → 이 방법 쓰니까 로직 코드가 확실히 깔끔해진다 ㄷㄷ

• 반복하지 마라!

  • 중복은 소프트웨어에서 모든 악의 근원이다

• 구조적 프로그래밍

  • 모든 함수와 함수 내 모든 블롱게 입구와 출구가 하나만 존재해야 한다. → 함수는 return 문이 하나여야 한다
  • break, continue, goto 는 사용하면 안된다 → 얼리 리턴 쓰라는건가

제 4장 주석

일단 읽기 전에 주석에 대한 나의 생각은 TODO 를 제외하고는 안써도 된다 이다. → TODO도 잘 안쓰긴한다
함수와 변수의 네이밍을 통해 주석의 역할을 대신할 수 있다는 생각인데 이 책은 어떨까

주석은 '순수하게 선하지' 못하다
주석이 필요한 상황에 처하면 곰곰이 생각하기 바란다. 상황을 역전해 코드로 의도를 표현할 방법은 없을까?
주석은 너무 자주 거짓말을 한다

• 주석은 나쁜 코드를 보완하지 못한다
  • 표현력이 풍부하고 깔끔하며 주석이 거의 없는 코드가, 복잡하고 어수선하며 주석이 많이 달린 코드보다 훨씬 좋다
• 좋은 주석
  • 법적인 주석
    • 저작권 정보, 소유권 정보
  • 정보를 제공하는 주석
    • 기본적인 정보를 주석으로 제공하면 편리 → 뭐야 쓰지 않는 코드를 작성하라면서요
  • 의도를 설명하는 주석
    • 저자의 문제 해결방식은 틀릴 수 있는데 의도는 분명히 드러남
  • 의미를 명료하게 밝히는 주석
    • 인수나 반환값이 표준 라이브러리나 변경하지 못하는 코드에 속한다면 의미를 명료하게 밝히는 주석이 용이
  • 결과를 경고하는 주석
    • 다른 프로그래머에게 결과를 경고할 목적으로 주석 사용
  • TODO 주석
    • 때로는 앞으로 할 일을 주석으로 남겨두면 편하다
    • 하지만 어떤 용도로 사용하든 시스템에 나쁜 코드를 남겨 놓는 핑계가 되어서는 안된다
  • 중요성을 강조하는 주석
    • 자칫 대수롭지 않다고 여겨질 뭔가의 중요성을 강조하기 위해서도 주석을 사용

  근데 이 좋은 주석 이라는 것들은 잘못된 정보를 가지지 않은 주석이라는 전제가 깔려 있어야 할 것 같다는 생각이다

• 나쁜 주석
  • 대다수 주석이 이 범주에 속한다
  • 주절거리는 주석
    • 이해가 안되어 다른 모듈까지 뒤져야 하는 주석은 독자와 제대로 소통하지 못하는 주석이다
  • 같은 이야기를 중복하는 주석
    • 자칫하면 코드보다 주석을 읽는 시간이 더 오래 걸릴 수 있음
  • 오해할 여지가 있는 주석
    • 의도는 좋았으나 프로그래머가 딱 맞을 정도로 엄밀하게는 주석을 달지 못할 수 있음
    • 주석에 담긴 살짝 잘못된 정보로 인해 큰일날 수 있음
  • 의무적으로 다는 주석
    • 코드만 헷갈리게 만들며, 거짓말할 가능성을 높이며, 잘못된 정보를 제공할 여지만 만듦
  • 이력을 기록하는 주석
    • 요즘은 소스코드 관리 시스템이 있어서 안해도 됨 → git 최고
  • 있으나 마나 한 주석
    • 너무 당연한 사실을 언급하며 새로운 정보를 제공하지 못하는 주석
  • 함수나 변수로 표현할 수 있다면 주석을 달지 마라
    • 주석이 필요하지 않도록 코드를 개선
  • 위치를 표시하는 주석
    • 가독성만 낮춤
  • 닫는 괄호에 다는 주석
  • 주석 처리한 코드
  • HTML 주석 → 혐오 그 자체라고 함 ㄷㄷㄷㄷ
  • 너무 많은 정보
  • 모호한 관계
    • 주석과 주석이 설명하는 코드는 둘 사이 관계가 명백해야 한다
  • 함수 헤더
    • 짧은 함수는 긴 설명이 필요 없다

좋은 주석은 조금인데 나쁜 주석은 한바가지다...
주석은 지양해야겠다