이펙티브 코틀린 - 1부 2장

2장 가독성

코틀린은 간결성을 목표로 설계된 프로그래밍 언어가 아니라, 가독성을 좋게 하는 데 목표를 두고 설계된 프로그래밍 언어

아이템 11: 가독성을 목표로 설계하라

프로그래밍은 쓰기보다 읽기가 중요하다는 의미, 따라서 항상 가독성을 생각하면서 코드를 작성해야 한다.
가독성이란 코드를 읽고 얼마나 빠르게 이해할 수 있는지를 의미한다.
사용 빈도가 적은 관용구는 코드를 복잡하게 만든다. 관용구들을 한 문장 내부에 조합해서 사용한다면 복잡성은 훨씬 더 빠르게 증가한다.
익숙하지 않은 구조를 사용하면, 잘못된 동작을 코드로 보면서 확인하기 어렵다.
'인지 부하'를 줄이는 방향으로 코드를 작성
 
가변 프로퍼티는 쓰레드와 관련된 문제를 발생시킬 수 있으므로, 스마트 캐스팅이 불가능하다.
일반적으로 안전 호출 let을 사용. let을 사용하는 경우

• 연산을 아규먼트 처리 후 이동시킬 때
• 데코레이터를 사용해서 객체를 랩할 때

문제가 되는 경우 비용을 지불할 만한 가치가 없는 코드에 비용을 지불하는 경우다.
 
예제가 컨벤션을 위반한 내용들

• 연산자는 의미에 맞게 사용해야 한다
• '람다를 마지막 아규먼트로 사용한다'
• 함수 이름과 처리 내용이 맞아야 한다.
• 이미 있는 내용을 다시 만들 필요는 없다.

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

연산자 오버로딩은 굉장히 강력한 기능이지만 위험할 수 있다.
코틀린에서 각 연산자의 의미는 항상 같게 유지된다.
연산자 오버로딩을 통해 자유가 많은 개발자는 해당 기능을 오용하게 만든다.
연산자는 대응함수에 의해서 코드로 변환된다.
예제에 나오는 팩토리얼을 계산하기 위해 !(not 논리 부정) 연산자를 사용하면 안된다.
관례에 어긋나기 때문
 
연산자의 의미가 명확하지 않다면, infix를 활용한 확장 함수를 사용하는 것이 좋다.
톱레벨 함수를 사용하는 것도 좋다.
 
연산자 오버로딩 규칙을 무시해도 되는 중요한 경우는 DSL을 설계할 때다.

아이템 13: Unit?을 리턴하지 말라

Unit?으로 Boolean을 표현하는 것은 오해의 소지가 있으며, 예측하기 어려운 오류를 만들 수 있다.
기본적으로 Unit?을 리턴하거나, 이를 기반으로 연산하지 않는 것이 좋다.

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

var, val을 이용한 변수 선언 시 타입이 명확하게 보이지 않는다면, 타입을 지정하자.
타입 추론은 강력하지만, 코드상으로 확인할 수 없다면 가독성이 떨어지는 것이다.

아이템 15: 리시버를 명시적으로 참조하라

리시버가 명확하지 않다면, 명시적으로 리시버를 적어서 이를 명확하게 해라.
명확하게 작성하면, 코드를 안전하게 사용할 수 있을 뿐만 아니라 가독성도 향상된다.
 
DSL설계할 때 암묵적으로 외부 리시버를 사용하는 것을 막는 DslMarker라는 메타 어노테이션을 사용

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

var을 사용해서 만든 읽고 쓸 수 있는 프로퍼티는 게터와 세터를 정의할 수 있다. 이러한 프로퍼티를 파생 프로퍼티라고 부른다.
프로퍼티는 필드가 필요 없다.
코틀린은 인터페이스에도 프로퍼티를 정의할 수 있다.
프로퍼티를 위임할 수 있다.
프로퍼티는 본질적으로 함수이므로, 확장 프로퍼티를 만들 수도 있다.
프로퍼티를 함수 대신 사용할 수도 있지만, 그렇다고 완전히 대체해서 사용하는 것은 좋지 않다.
프로퍼티 대신 함수를 사용하는 것이 좋은 경우

• 연산 비용이 높거나 복잡도가 O(1)보다 큰 경우
• 비즈니스 로직을 포함하는 경우
• 같은 동작을 연속으로 두 번 했는데, 다른 값이 나올 수 있다면 함수를 사용하는 것이 좋다.
• 변환의 경우
• 게터에서 프로퍼티의 상태 변경이 일어나야 하는 경우

프로퍼티는 상태 집합을 나타내고 함수는 행동을 나타낸다고 생각한다.

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

변수를 사용할 때도 이름 있는 아규먼트를 함께 활용하면 좋다.
 
아규먼트를 사용하면 코드가 길어지지만, 두 가지 장점이 있다

• 이름을 기반으로 값이 무엇을 나타내는지 알 수 있다.
• 파라미터 입력 순서와 상관 없으므로 안전하다.

성능에 영향을 줄 것 같아서 걱정한다면 인라인 클래스를 사용
파라미터 순서를 잘못 입력하는 문제가 발생할 수 있다.
이름있는 아규먼트 사용을 추천하는 경우

• 디폴트 아규먼트의 경우
• 같은 타입의 파라미터가 많은 경우
• 함수 타입의 파라미터가 있는 경우(마지막인 경우 제외)

 
디폴트 값을 갖는 옵션 파라미터의 설명이 명확하지 않다. 따라서 이러한 것들은 이름을 붙여서 사용하는 것이 좋다
 
파라미터에 같은 타입이 있다면, 잘못 입력했을 때 문제를 찾아내기 어려울 수 있다.
 
일반적으로 함수 타입 파라미터는 마지막 위치에 배치하는 것이 좋다.함수 이름이 함수 타입 아규먼트를 설명해 주기도 한다.
모든 함수 타입 아규먼트는 이름 있는 아규먼트를 사용하는 것이 좋다.
여러 함수 타입의 옵션 파라미터가 있는 경우에는 더 헷갈린다.

아이템 18: 코딩 컨벤션을 지켜라

컨벤션을 지키면 좋은 이유

• 어떤 프로젝트를 접해도 쉽게 이해할 수 있다.
• 다른 외부 개발자도 프로젝트의 코드를 쉽게 이해할 수 있다.
• 다른 개발자도 코드의 작동 박식을 쉽게 추측할 수 있다.
• 코드를 병합하고, 한 프로젝트 코드 일부를 다른 코드로 이동하는 것이 쉽다.

툴 두 가지

• Intellij 포메터
• ktlint

프로젝트의 컨벤션은 반드시 지켜주는 것이 좋다.
마치 한 사람이 작성한 것처럼 작성되어야 한다.