본문 바로가기

분류 전체보기

ㅤㅤㅤㅤㅤ
By 쟈 미
[이펙티브 코틀린] Item18. 코딩 컨벤션을 지켜라 지켜야하는 이유 어떤 프로젝트를 접해도 쉽게 이해할 수 있다 다른 외부 개발자도 프로젝트의 코드를 쉽게 이해할 수 있다 다른 개발자도 코드의 작동 방식을 쉽게 추측할 수 있다 코드를 병합하고, 한 프로젝트의 코드 일부를 다른 코드로 이동하는 것이 쉽다 컨벤션 두가지 도구 intellij 포매터 ktlink 파라미터 컨벤션 코틀린에서 많은 파라미터를 갖고있는 클래스, 함수는 각각의 파라미터를 한 줄씩 작성하는 방법을 사용한다 class Person( val id: Int =0, val name: String ="", val surname: String = "" ): Human(id,name) public fun Iterable.joinToString( separator: CharSequence = ", ".. Reading Record/이펙티브 코틀린 2022. 4. 26.
ㅤㅤㅤㅤㅤ
By 쟈 미
[이펙티브 코틀린] Item17. 이름 있는 아규먼트를 사용하라 이름있는 아규먼트 (named argument) - 파라미터가 명확하지 않은 경우에는 이를 집적 지정해서 명확하게 만들어준다. 이름있는 아규먼트의 장점 이름을 기반으로 값이 무엇을 나타내는지 알 수 있다 파라미터 입력 순서와 상관이 없어 안전하다. 성능에 영향을 줄 것 같으면, 인라인 클래스를 사용하라 : 그러나 파라미터 순서 잘못 입력하는 경우 생길 수 있다. 이름 있는 아규먼트를 사용해야하는 경우 3가지 1) 디폴트 아규먼트의 경우 함수 이름은 필수 파라미터들과 관련되어있어, 디폴트 값을 갖는 옵션 파라미터(optional parameter)의 설명이 명확하지 않다. 2) 같은 타입의 파라미터가 많은 경우 이름있는 아규먼트를 사용하지 않으면 잘못 입력했을 때 문제를 찾아내기 어려울 수 있다. 3) 함.. Reading Record/이펙티브 코틀린 2022. 4. 26.
ㅤㅤㅤㅤㅤ
By 쟈 미
[이펙티브 코틀린] Item16. 프로퍼티는 동작이 아니라 상태를 나타내야 한다. 자바의 필드와 코틀린의 프로퍼티는 완전 다른 개념이다. 프로퍼티의 특징 1 ) 프로퍼티는 사용자 정의 세터와 게터를 가질 수 있다. field 식별자 : 프로퍼티의 데이터를 저장해두는 백킹 필드(backing field)에 대한 레퍼런스 > 세터와 게터의 디폴트 구현에 사용 2 ) 파생 프로퍼티 (derrived property) var을 사용해서 만든 읽고 쓸 수 있는 프로퍼티는 게터와 세터 정의가 가능하다. val로 읽기 전용 프로퍼티를 만들때는 field가 만들어지지 않는다 3 ) 프로퍼티는 필드가 필요가 없다. 개념적으로 접근자를 나타낸다 (val 는 게터, var는 게터와 세터) 그래서 인터페이스에서 프로퍼티 정의가 가능 프로퍼티 위임 (property delegation)이 가능하다 확장 프로.. Reading Record/이펙티브 코틀린 2022. 4. 26.
ㅤㅤㅤㅤㅤ
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.

티스토리툴바