[item 16] 프로퍼티는 동작이 아니라 상태를 나타내야함
자바에서 코틀린으로 넘어올 경우 자주 혼동이 오는 개념이다. 책에서 나왔듯이 프로퍼티는 필드가 아니라, getter / setter 에 가깝다. 필드처럼 쓸 수 있는 것은 표현 방식이 유사할 뿐이다.
getter/ setter 를 오버라이딩 할 수 있다보니, 가끔씩 비즈니스 로직 (로깅 등)을 끼워넣고 싶은 유혹이 들 때가 있는데 책에서는 이에 대해 명확히 밝히고 있다.
프로퍼티는 상태를 나타내거나 설정하기 위한 목적으로만 사용하는 것이 좋고, 다른 로직 등을 포함하지 않아야 합니다.
어떤 것을 프로퍼티로 표현해야하는지 감이 오지 않는 경우를 대비한 팁도 제공한다.
‘이 프로퍼티를 함수로 정의할 경우, 접두사로 get 또는 set 을 붙일 것인가?’
그외 팁으로는
- 시간 복잡도 O(1) 을 넘어가는 연산을 지양
- 비즈니스 로직 지양
- 비결정적인 경우 지양
- getter 에서 상태변경을 시도하는 것을 지양
[item 17] 이름 있는 아규먼트를 사용하라
named argument 를 사용하거나 파라미터를 명확하게 선언한 후 전달하는 것. 개인적으로 argument 의 개수와 타입과 무관하게 name 을 붙혀주는 편이다.
앞으로 얼마나 추가될지 알 수 없고, 함수에 직접 진입하지 않아도 context 를 확보하기 용이하기 때문이다. 간혹, IDE 의 지원으로 이름을 붙히지 않아도 확인이 가능하므로 붙히지 않는 경우를 본 적이 있는데(…) 코드리뷰하는 입장에서는 똑같이 안보인다. 그리고 IDE 의존적인 내용이 코드에 반영되어서는 안된다.
[item 18] 코딩 컨벤션을 지켜라
코드 리뷰에서 적지않은 부분을 차지하는 부분. 사실 다소 명확한 케이스는 룰로 지정하여 린트를 돌리는게 시간/에너지 상으로 이득이다.
단, 서비스 specific 한 도메인이나 외부 의존성 등에 의해 일반적인 룰로 커버할 수 없는 경우는 리뷰로 조율하고, 룰을 만들어 동일한 포인트로 리뷰 혹은 논의가 계속 발생하지 않는 것이 best 라고 생각한다.