본문 바로가기

Reading Record/이펙티브 코틀린

ㅤㅤㅤㅤㅤ
By 쟈 미
[이펙티브 코틀린] Item15. 리시버를 명시적으로 참조하라 this - 함수와 프로퍼티를 지역 또는 톱레벨 변수가 아닌 다른 리시버로부터 가져온다는 것을 나타낼 수 있다 - 확장 리시버를 명시적으로 참조가 가능하다. (확장 메서드에서의 this) 여러 개의 리시버 스코프 내부에 둘 이상의 리시버가 있는 경우, 리시버를 명시적으로 나타내자 > 짧게 적을 수 있다는 이유만으로 리시버를 제거하지 말자. 레이블 없이 리시버를 사용하면 가장 가까운 리시버를 의미한다. 리시버는 주로 apply, with, run, also, let에서 사용된다. @ : qualified this - outer scope에 있는 this를 접근할 수 있다. [코드 삽입하기] DSL 마커 코틀린 DSL : 여러 리시버를 가진 요소들이 중첩되어도 리시버를 명시적으로 붙이지 않도록 설계되어 있다.. Reading Record/이펙티브 코틀린 2022. 4. 26.
ㅤㅤㅤㅤㅤ
By 쟈 미
[이펙티브 코틀린] Item14. 변수 타입이 명확하지 않은 경우 확실하게 지정하라 val data = getSomeData() val data: UserData = getSomeData() 코틀린의 타입추론 : 개발 시간을 줄여준다. 유형이 명확할 때 코드가 짧아지므로 가독성이 크게 향상된다. 유형이 명확하지 않을 때는 코틀린의 타입추론을 남용하면 좋지 않다. 가독성 향상 이외에 안전을 위해서도 타입을 지정하는 것이 좋다 (item3. 최대한 플랫폼 타입을 사용하지 말라 / item4. inffered 타입으로 리턴하지 말라) Reading Record/이펙티브 코틀린 2022. 4. 26.
ㅤㅤㅤㅤㅤ
By 쟈 미
[이펙티브 코틀린] Item13. Unit?을 리턴하지 말라 // Boolean 으로 사용하는 경우 fun keyIsCorrect(key: String) : Boolean = // … if(!keyIsCoreect(key) return // 같은 코드를 Unit?으로 사용하는 경우 fun verifyKey(key:String): Unit? = //… verifyKey(key) ?: return Unit? 으로 Boolean을 표현하는 것은 오해의 소지가 있으며, 예측하기 어려운 오류를 만들 수 있다. 위 예제처럼 같은 역할로 사용이 가능하지만, 올바르지 않은 용례이기 때문에 Boolean을 사용하자. Reading Record/이펙티브 코틀린 2022. 4. 26.
ㅤㅤㅤㅤㅤ
By crud
[이펙티브 코틀린] Item12. 연산자 오버로드를 할 때는 의미에 맞게 사용하라 연산자 오버로딩은 강력한 기능이지만, 책임이 따른다. fun Int.factorial(): Int = (1..this).product() fun Iterable.product(): Int = fold(1) { acc, i -> acc * i } operator fun Int.not() = factorial() not은 논리 연산에 사용해야지, 팩토리얼 연산에 사용하면 안된다. 코틀린에서 각 연산자의 의미는 항상 같게 유지해야 된다. 분명하지 않은 경우 infix를 활용한 확장 함수를 사용하자 infix fun Int.timesRepeated(operation: ()->Unit)={ repeat(this) { operation() } } 3 timeRepeated { print("Hello")} 톱 레벨 .. Reading Record/이펙티브 코틀린 2022. 4. 19.
ㅤㅤㅤㅤㅤ
By crud
[이펙티브 코틀린] Item11. 가독성을 목표로 설계하라 인식 부하 감소 if (person != null && person.isAdult) { view.showPerson(person) } else { view.showError() } person?.takeIf { it.isAdult } ?.let(view::showPerson) ?: view.showError() 일반적인 관용구 사용은 이해하기 쉽다 코틀린에서 자주 사용되는 관용구 takeIf,let,엘비스 연산자는 코틀린 개발자는 익숙하지만, 숙련된 개발자만을 위한 코드는 좋은 코드가 아니다 takeIf public inline fun T.takeIf(predicate: (T) -> Boolean): T? = if (predicate(this)) this else null let inline fun T... Reading Record/이펙티브 코틀린 2022. 4. 19.
ㅤㅤㅤㅤㅤ
By crud
[이펙티브 코틀린] Item10. 단위 테스트를 만들어라 단위 테스트로 확인하는 내용 일반적인 유스 케이스 일반적인 오류 케이스와 잠재적인 문제: 제대로 동작하지 않을 거라고 예상되는 부분, 과거 문제가 발생했던 부분 에지 케이스와 잘못된 아규먼트 단위 테스트의 장점 코드에 대한 신뢰감 리펙토링 생산성 향상 단위 테스트의 단점 시간소요 - 장기적으로는 시간 단축 테스트를 작성할 수 있게 코드를 조정해야함 - 이러한 변경은 좋은 아키텍처로 이끌어줌 좋은 단위 테스트를 만드는 작업이 어려움 Reading Record/이펙티브 코틀린 2022. 4. 19.
ㅤㅤㅤㅤㅤ
By crud
[이펙티브 코틀린] Item9. use를 사용하여 리소스를 닫아라 Closeable 인터페이스를 구한혀는 리소스는 레퍼런스가 없어질 때 가비지 컬렉터가 처리한다. 자동 처리는 느리며 쉽게 처리되지 않아 close를 명시적으로 호출해주는 것이 좋다 java의 try with resource 같은 키워드가 없으므로 try finally로 처리가능하다 try finally로 처리할 시 try 예외 발생 후 finally 구문에서 예외가 발생하면 둘 중 하나의 예외만 전파된다 close 예외가 발생할 경우를 대비해 예외처리를 해주어야 한다. kotlin은 위 불편을 해소하기 위해 use 함수를 제공한다 코틀린의 확장함수로 제공 Closeable에 사용할 수 있다. @InlineOnly @RequireKotlin("1.2", versionKind = RequireKotlinVe.. Reading Record/이펙티브 코틀린 2022. 4. 19.
ㅤㅤㅤㅤㅤ
By crud
[이펙티브 코틀린] Item8. 적절하게 null을 처리하라 null을 안전하게 처리하기 안전호출 printer?.print() 스마트 캐스팅 if(printer != null) printer.print() 엘비스 연산자 printer?.name ?: "Unnamed" printer?.name ?: return printer?.name ?: throw Error("error") Not-null assertion(!!)과 관련된 문제 !!문은 nullability가 제대로 표현되지 않는 라이브러리를 사용할 때 정도에만 사용해야함 미래에 코드가 어떻게 변화할지 모르니 현재 null이 아니라고 !!문을 쓰면 안된다. !! 연산자 사용은 최대한 피하자 의심 없는 nullability 피하기 nullability를 안전하게 처리할 수 있는 함수 사용 List getOrNu.. Reading Record/이펙티브 코틀린 2022. 4. 19.

티스토리툴바