스터디/이펙티브코틀린

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

코드에서 아규먼트의 의미가 명확하지 않은 경우는 모든 코드를 작성하다 느낄 수 있는 부분이다. val text = (1..10).joinToString("|") // `|`이 무엇을 의미하는지? joinToString에 대해 알고 있다면 구분자라는 것을 알 수 있지만 아니라면 이해하기 힘들 수 있다. 파라미터가 명확하지 않은 경우에는 이름있는 아규먼트(named argument)를 이용하여 명확하게 만들자. val text = (1..10).joinToString(separator = "|") separator를 변수로 선언하여 사용해도 좋지만 아래와 같은 문제가 발생 할 수 있다. 실제로 코드에서 사용되는지 확신 할 수 없다. (사실 이건 IDE가 다 알려주니 큰 문제가 되지 않는다.) 변수를 잘못 만..

2023.04.27 게시됨

스터디/이펙티브코틀린

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

코틀린의 프로퍼티는 자바의 필드와 비슷해 보이나 다른 개념이다. var: name: String? = null get() = field?.toUpperCase() set(value) = { if(!value.isNullOrBlank()){ field = value } } 위와 같이 파생 프로퍼티라 불리는 var를 사용해서 만든 프로퍼티는 위와같이 게터와 세터를 정의할 수 있다. 이 때 field는 데이터를 저장하는 백킹(backing) 필드에 대한 레퍼런스이다. 백킹 필드는 따로 만들지 않아도 디폴트로 생성된다. 단, val를 이용한 읽기 전용 프로퍼티의 경우 생성되지 않는다. 프로퍼티는 필드가 필요하지 않다. 개념적으로 접근자라고 생각하면 된다. 따라서 val의 경우 getter, var의 경우 get..

2023.04.27 게시됨

스터디/이펙티브코틀린

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

무언가를 더 자세하게 설명하기 위해서, 명시적으로 긴 코드를 사용할 때가 있듯이 리시버도 명시적으로 적어주는 것이 좋다. 단지, 짧게 적을 수 있다는 이유만으로 리시버를 제거하지 말자. 여러 개의 리시버가 있는 상황에는 명시적으로 적어주는 것이 좋다. 여러 개의 리시버 특히 스코프 내부에 둘 이상의 리시버가 있는 경우, 리시버를 명시적으러 적어주도록 하자. 이를 지켜주면 코드를 오해하고 작성하거나, 의도하지 않은 방향으로 코드가 동작하는걸 미연에 방지할 수 있다. AS-IS class Node(val name: String) { fun makeChild(childName: String) = create("$name.$childName") .apply { print("Create $name") } fun ..

2022.03.25 게시됨

스터디/이펙티브코틀린

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

앞장에서도 계속해서 언급해왔듯이 프로그래밍은 쓰기보다 읽기가 중요하다. 따라서 가독성을 위해 코드를 설계할 때 읽는 사람에게 중요한 정보를 숨겨서는 안된다. 코드를 읽으면서 숨겨진 변수 타입을 확인하기 위해 함수 내부로 일일히 들어가서 확인해야 한다면 당연히 가독성은 떨어질 수 밖에 없다. 사람이 작업을 위해 잠깐 동안 기억할 수 있는 기억력의 총량은 그리 크지않다. 다시 말해 한정된 사람의 메모리 자원을 쓸데없이 낭비하는 것은 좋지 않다. 물론 매번 변수타입을 명확하게 하라는 것은 아니지만 적절히 가독성을 위해서 변수타입을 명확하게 지정해 주도록 하자. 그러면 타입 안정성까지 덤으로 얻어 갈 수 있다. (아이템 4 - inferred 타입으로 리턴하지 말라)

2022.03.25 게시됨

스터디/이펙티브코틀린

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

The type with only one value: the Unit object. This type corresponds to the void type in Java. https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-unit/ Unit은 공식문서에서 볼 수 있듯 한가지 값을 가질 수 있는 타입을 나타내는 객체이다. Java에서 void 와 비슷한 타입으로 볼 수 있다. (자바의 void 는 값을 가지지 않지만..) Unit? 는 Unit 이나 null 값을 가질 수 있다. 그래서 이를 이상하게 사용하면 마치 Boolean 처럼 사용할 수 있다. 그렇게 사용하지마라 ~처럼 사용한다는 것 자체가 의도를 벗어난 행위를 하는것이다. 예측하기 어려운 오류를 만들 수..

2022.03.25 게시됨

스터디/이펙티브코틀린

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

연산자 오버로딩은 그 이름의 의미에 맞게 사용하자. 큰 힘에는 큰 책임이 따른다. 코틀린에서 ! 연산자는 boolean의 반대를 나타내는 not 연산을 의미한다. 이런 연산자를 팩토리얼을 표현하기 위해 아래와 같이 표현한다면 다음과 같다. 10 * !6 그리고 위 코드를 not으로 읽어보면 아래와 같이 된다. 10 *6.not() 오버로딩을 이런식으로 활용하면 혼란스럽고 오해의 소지가 있다. 코틀린의 모든 연산자는 별칭이다. 즉, 본래의 이름이 있기 때문에 그 의미를 벗어나도록 오버로딩하면 안된다. 분명하지 않은 경우 그런데 오버로딩을 한 연산자가 이름의 뜻을 제대로 의미하는지(관례를 충족하는지) 확신이 들지 않을 때가 있다. 아래의 경우 * 는 함수를 여러번 실행시키는 의미로 사용되었다. 3 * pri..

2022.03.25 게시됨

스터디/이펙티브코틀린

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

프로그래밍은 쓰기보다 읽기가 중요하다 고로 항상 가독성을 생각하면서 코드를 작성해야 한다. 그렇지 않으면 오류를 찾기위해 코드를 작성할 때보다 오랜 시간 코드를 읽는 자신을 발견할 수 있다. 개발자가 코드를 작성하는 데는 1분 걸리지만, 이를 읽는 데는 10분이 걸린다. by 로버트 마틴 인식 부하 감소 가독성이란 코드를 읽고 얼마나 빠르게 이해할 수 있는지를 의미한다. 경험과 인식에 대한 과학으로 만들어진 어느 정도의 규칙이 있다. fun readGood(person: Person?, view: View) { if (person != null && person.isAdult) { view.showPersion(person) } else { view.showError() } } fun readBad(pe..

2022.03.25 게시됨

스터디/이펙티브코틀린

아이템 10 - 단위 테스트를 만들어라

코드를 안전하게 만드는 방법은 다양한 종류의 테스트를 하는 것이다. 대부분의 관리자에게 테스트는 사용자 관점에서 애플리케이션 외부적으로 제대로 작동하는지 확인하는 것이 목표이다. 물론 개발자에게도 유용하지만 충분하지 않다. 개발자는 각 요소가 올바르게 작동한다는 것을 보증하고 빠른 피드백을 받으며 개발하기 위해 단위 테스트가 필요하다. 테스트 내용 단위 테스트는 일반적으로 아래 내용을 확인함으로써 개발자가 만들고 있는 요소가 제대로 동작하는지를 빠르게 피드백해줄 수 있어 도움이 된다. 일반적인 유스 케이스: 예상되는 일반적인 방법 일반적인 오류 케이스, 잠재적인 문제: 동작하지 않을 거라고 예상되는 일반적인 부분, 과거에 문제가 발생한 부분 Edge 케이스, 잘못된 매개변수의 입력 테스트 장점 테스트로 ..

2022.03.07 게시됨

스터디/이펙티브코틀린

아이템 9 - use를 사용하여 리소스를 닫아라

use 메서드를 사용하면 Closeable/ AutoCloseable 를 구현한 객체를 쉽고 안전하게 처리할 수 있다. 더 이상 필요하지 않을때, close 메서드를 사용해서 명시적으로 닫아야하는 Resource들이 있다. 보통 이러한 Resource는 AutoCloseable 을 상속받는 Closeable 을 구현하고 있다. 이러한 리소스는 최종적으로 리소스에 대한 레퍼런스가 없어질 때, GC가 알아서 처리하지만 굉장히 느린 작업이고 비용이 비싸다. 그러므로 명시적으로 close 메서드를 호출해주는것이 좋은데, 자바를 사용할 때 try-with-resources를 사용했던 것 처럼 코틀린에서 use를 사용하도록 하라. 예제 use 는 아래와 같이 Closeable 를 구현한 객체에 사용할 수 있다. f..

2022.03.05 게시됨