본문 바로가기
[Effective Kotlin] Item 15 : Consider referencing receivers explicitly 이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서 Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다. # extension receiver 란 "this" 같은 녀석을 말한다. Many receivers # 명시적인 receiver 를 사용하는 것은 scope 내에서 1개 이상의 receiver 가 있는 경우 유용하다. class Node(val name:String){ fun makeChild(childName: String) = create("$name.$childName").apply{ print("Created ${name}") } fun create(name : Strin.. 2022. 3. 12.
[Effective Kotlin] Item 14 : Specify the variable type when it is not clear 이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서 Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다. # val data = getSomeData() 위와 같이 compiler 에 의한 type inference 는 되지만, human 에 의해 type 을 바로 알기 어려운 경우 (가독성을 저해하는 경우) 명시적으로 타입을 붙여주는 것이 좋다. # 코드를 읽는 사람이 꼭 IDE 에서 보라는 법이 없기 때문에 IDE 가 제공하는 return type 보기 기능을 활용할 수 없을 수 있고, return type 확인을 위해 함수로 jump in 이 쉽지 않은 경우도 있다. # 모호한 .. 2022. 3. 11.
[Effective Kotlin] Item 13 : Avoid returning or operating on Unit? 이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서 Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다. # Unit? return 이 사용될법한 곳은 아래와 같은 케이스 뿐이라 생각. if (isKeyCorrect(key) == false) return verifyKey(key) ?: return // Unit? return case 이런 경우 boolean 으로 대체될 수 있고 더 일반적인 사용방법이며, Unit? return 은 혼란을 가져올 수 있어 피하는 게 좋다. 끝 2022. 3. 10.
[Effective Kotlin] Item 12 : Operator meaning should be consistent with its function name 이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서 Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다. # Operator overloading 은 강력한 기능이다. 하지만 위험하기도 하다. operator 의 의미는 그대로 유지하여야 한다. Unclear cases # 의미가 대충 맞는 다른 구현을 할 때가 있다. 그러나 이 경우에도 infix top-level function 을 정의해서 해결하는 것이 좋고, stdlib 에서 제공하는것으로 쉽게 대체 가능한지를 확인하는 것도 좋다. When is it fine to break this rule? # DSL 을 만들 때가 oper.. 2022. 3. 9.
[Effective Kotlin] Item 11 : Design for readability 이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서 Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다. # 어떤 멍청이도 컴퓨터가 이해할 수 있는 코드를 작성할 수 있다. 그러나 훌륭한 프로그래머는 사람이 이해할 수 있는 코드를 작성한다. # 프로그래머들이 코드를 작성하는데 1분 쓴다면, 읽는데 10분을 사용한다는 통계가 있다. 프로그래밍은 대부분이 '쓰기' 보다는 대부분 '읽기' 라고 할 수 있다. Reducing cognitive load # if (person != null && person.isAdult){ view.showPerson(person) }else{ view.sh.. 2022. 3. 8.
[Effective Kotlin] Item 10 : Write unit tests 이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서 Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다. # unit test 로는 보통 아래의 것들을 체크한다. 일반적인 use case (happy path) Common error case, 잠재적 문제 - 문제가 발생할 수 있는 경우나, 과거에 생겼던 문제 Edge-case and illegal arguments - Int.MAX_VALUE, null 등의 케이스 # unit test 가 있으면 아래의 장점이 있다. 코드에 대한 신뢰도가 더 생긴다. refactor 를 하는데 자신감이 생긴다. 특정 상황들에서는 수동으로 체크하는 .. 2022. 3. 7.
[Effective Kotlin] Item 9 : Close resource with use 이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서 Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다. # InputStream, OutputStream, java.sql.Connection, java.io.Reader(FileReader, BufferedReader ...), java.new.Socket, java.util.Scanner 등이 close 해줘야 하는 resource 의 예이다. 이들은 Closeable interface 를 구현하였고, 이는 AutoCloseable 을 상속하였다. # 이 Closable 들을 명시적으로 close 해주지 않아도 GC 에 의해 결국 .. 2022. 3. 6.
[Effective Kotlin] Item 8 : Handle nulls properly 이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서 Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다. # null 은 해석의 여지가 다분하기 때문에, 가능한한 의미가 명확해야 한다. # null 은 3가지 형태로 다뤄질 수 있다. ?., smart casting, elvis operator 등을 사용하여 안전하게 다루기 error 던지기 nonnull 로 refactor 하기 Handling nulls safely Throw an error # null 이 아니어야만 하는 상황에서, null 일 경우 error 를 던짐으로써 programmer 가 예상하지 못한 상황을 발견할 수 .. 2022. 3. 5.
[Effective Kotlin] Item 7 : Prefer null or Failure result when the lack of result is possible 이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서 Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다. # 원하는 결과를 제공할 수 없을 때 다음과 같은 방법을 사용한다. null 또는 실패에 관련된 sealed class 를 return exception 던지기 exception 이 정보를 제공하는 용도로 사용해서는 안 된다. # 모든 exception 은 진짜 예외적인 상황에서만 사용되어야 한다. # exception 전파는 가독성을 떨어뜨리며 이상한 상황에 빠지게 만들 수 있다. Kotlin 에서 모든 exception 은 unchecked 이다. exception 은 정말 예.. 2022. 3. 4.
반응형

티스토리툴바