2장 가독성

2장까지 읽으면서 느낀점은 이 책에서는 굉장히 당연한 이야기들을 서술한듯한 느낌을 받는다.(반론의 여지가 딱히 없는?)

Item 정리

Item 11 가독성을 목표로 설계하라

사람에 따라서 가독성에 대한 관점이 다르다, 많은 개발에서 함수 이름을 어떻게 지어야 하는지, 어떤 것이 명시적이여야 하는지, 어떤 것이 암묵적이어야 하는지, 관용구를 사용해야 하는지 등 프로그래밍은 표현력의 예술이며 이를 위해 이해하고 기억해야 하는 몇 가지 규칙이 있다.

Item 12 연산자 오버로드를 할 때는 의미에 맞게 사용하라

연산자 오버로딩은 그 이름의 의미에 맞게 사용해야하며 연산자 의미가 명확하지 않다면, 연산자 오버로딩을 사용하지 않는 것이 좋다.

Item 13 Unit?을 리턴하지 말라

Unit?을 쉽게 읽을 수 있는 경우는 거의 없다. 오해를 불러 일으키기 쉽기 때문에 Boolean을 사용하는 형태로 변경하는 것이 좋다. 기본적으로 Unit?을 리턴하거나, 이를 기반으로 연산하지 않는 것이 좋다.

Item 14 변수 타입이 명확하지 않은 경우 확실하게 지정하라

가독성 향상 이외에 안전을 위해서도 타입을 지정하는 것이 좋다. 타입은 개발자와 컴파일러 모두에게 중요한 정보이다. 그렇다고 타입을 무조건 지정하라는 것이 아니라 상황에 맞게 사용해야 한다.

Item 15 리시버를 명시적으로 참조하라

짧게 적을 수 있다는 이유만으로 리시버를 제거하지 말아야 한다. 여러 개의 리시버가 있는 상황 등에는 리시버를 명시적으로 적어 주는 것이 좋다. 리시버를 명시적으로 지정하면, 어떤 리시버의 함수인지를 명확하게 알 수 있으므로, 가독성이 향상된다.

Item 16 프로퍼티는 동작이 아니라 상태를 나타내야 한다.

Item 17 이름 있는 아규먼트를 사용하라

이름 있는 아규먼트는 디폴트 값들을 생략할 때만 유용한 것이 아니다.

Item 18 코딩 컨벤션을 지켜라

주요 아젠다

가독성이라는 장 자체에서 아젠다를 뽑아내기가 어렵다고 생각하여(하지만 이는 코틀린은 많이 사용해보지 못한 결과) 주로 스터디장(멘토)의 주도하에 가독성에 대한 생각과 코드를 읽는데 얼마나 많은 시간을 투자하고 있는지 에 대하여 이야기를 하였습니다.

느낀점

해당 장도 가볍게 읽을 수 있던 장이였다. 평소에 팀 프로젝트를 진행하면서 코딩 컨벤션을 지키기 위해 구글 컨벤션 가이드와 같은 것들만 찾아보고 적용했었다. 하지만 책에서 강조하는 가독성있는 코드에 대해서 처음으로 생각을 해봤고, 코틀린은 변수타입을 자동으로 잡아주는 부분이 좋지만 가독성과 성능상 이슈가 발생할 수 있다는 점을 인지하였다. Java8 버전 이상을 사용할 때는 Stream과 Lamda를 사용하여 코드를 간소화하는게 무조건 좋다라는 인식이 있었지만 해당 장에서 나오는 Unit?과 같은 것들이 오히려 가독성을 해치고 읽기 어려운 코드로 읽는 비용이 발생한다는점에서 Lamda와 Stream을 언제 적용하면 좋은지에 대해서도 다시 한번 생각해보는 시간이 되었다.