728x90 공부/이펙티브코틀린48 아이템 11 - 가독성을 목표로 설계하라 프로그래밍은 쓰기보다 읽기가 중요하다는 의미 항상 가독성을 생각하면서 코드를 작성하자 가독성 이란 코드를 읽고 얼마나 빠르게 이해할 숙 있는지를 의미 인식 부하 감소 가독성은 사람에 따라 다르게 느낄 수 있지만, 일반적으로 많은 사람의 경험화 인식에 대한 과학으로 만들어진 어느정도의 규칙이 있다 우리의 뇌가 얼마나 많은 관용구(구조, 함수, 패턴)에 익숙해져 있는지에 따라 다르다. 익숙하지 않은 구조를 사용하면, 잘못된 동작을 코드를 보면서 확인하기 어렵다 기본적으로 '인지 부하'를 줄이는 방향으로 코드를 작성하자. class Item11Class( var name: String? = null, ) { var innerClass: Item11Class? = null fun printName() { if .. 2024. 4. 7. 아이템 10 - 단위 테스트를 만들어라 단위 테스트의 중요성은 널리 알고 있고, 이미 다들 하고 있는거라 읽고 넘어 감. 코드를 안전하게 만드는 가장 궁극적인 방법은 다양한 종류의 테스트를 하는 것 단위 테스트는 일반적으로 다음과 같은 내용을 확인한다 일반적인 use case 요소가 사용될 거라고 예상되는 일반적인 방법을 테스트 일반적인 오류 케이스와 잠재적인 문제 제대로 동작하지 않을 거라고 예상되는 일반적인 부분, 과거에 문제가 발생했던 부분 등을 테스트 엣지 케이스와 잘못된 아규먼트 Int 의 경우 Int.MAX_VALUE 를 사용하는 경우, nullable 의 같은경우 null 값으로 채워진 객체 등 피보나치 수는 양의정수로만 구할 수 있지만 음의 정수 등을 넣으면 아규먼트 자체가 잘못된 것 등을 테스트 회귀 테스트? 이미 검증된 코드.. 2024. 4. 7. 아이템 9 - use 를 사용하여 리소스를 닫아라 더 이상 필요하지 않을때, close 메서드를 사용해서 명시적으로 닫아야 하는 리소스가 있다 InputStream / OutputStream java.sql.Connection java.io.Reader java.new.Socket / java.uti.Scanner 등등 이러한 리소스들은 AutoCloseable 을 상속받은 Closeable 인터페이스를 구현하고 있다.이러한 모든 리소스는 최종적으로 리소스에 대한 레퍼런스가 없어질 때, 가바지 컬렉터가 처리한다. 하지만, 굉장히 느리며 그동안 리소스를 유지하는 비용이 많이 들어간다. public abstract class InputStream implements Closeable {...} public interface Closeable extends .. 2024. 4. 7. 아이템 8 - 적절하게 null 을 처리하라 null 을 리턴한다는 것은 함수에 따라서 여러 의미를 가질 수 있다 @Test fun `52_1`() { var name: String = "M" // String 을 Int 로 변환할 수 없을 경우 null 을 반환 val toIntOrNull = name.toIntOrNull() println("toIntOrNull: $toIntOrNull") val list = listOf(1, 2, 3) // 조건에 맞는 첫 번째 요소를 반환하거나 없으면 null 을 반환 val firstOrNull = list.firstOrNull { it % 4 == 0 } println("firstOrNull: $firstOrNull") // toIntOrNull: null // firstOrNull: null } 기본적.. 2024. 4. 4. 아이템 7 - 결과 부족이 발생할 경우 null 과 Failure 를 사용하라 함수가 원하는 결과를 만들어 낼 수 없을 때가 있는데 이러한 상황을 처리하는 매커니즘은 크게 다음과 같이 두 가지가 있다. null 또는 '실패를 나타내는 sealed 클래스(일반적으로는 Failure 라는 이름을 붙입니다)'를 리턴한다 예외를 throw 한다. 일단 예외는 정보를 전달하는 방법으로 사용해서는 안된다 예외는 잘못된 특별한 상황을 나타내야 하며, 처리되어야 한다 예외는 예외적인 상황이 발생했을 때 사용하는 것이 좋다. 많은 개발자가 예외가 전파되는 과정을 제대로 추적하지 못한다. 코틀린의 모든 예외는 unchecked 예외 입니다.따라서 사용자가 예외를 처리하지 않을 수도 있다. 예외는 예외적인 상황을 처리하기 위해서 만들어졌으므로 명시적인 테스트 만큼 빠르게 동작하지 않습니다. 일반적인 .. 2024. 3. 31. 아이템 6 - 사용자 정의 오류보다는 표준 오류를 사용하라 require, check, assert 함수를 사용하면 대부분의 코틀린 오류를 처리할 수 있다. 하지만 예측하지 못한 상황을 나타내야 하는 경우도 있는데, 가능하다면 이럴 때 코틀린이나 자바 표준 라이브러리에서 제공하는 표준 오류 클래스를 사용하면 좋다 표준오류코드: IllegalArgumentException, IllegalStateException, IndexOutOfBoundsException 등과 같이 일반적으로 널리 사용되는 예외 클래스 개인생각: 대부분 저렇게 사용하고 있고, 도메인마다 메인으로 처리하는 exception 클래스가 따로 있는 경우도 있어, 개발자 들끼리의 약속만 잘 정해져 있으면 크게 문제되지 않는다 라고 생각함. 고객에게 노출되는 코드 제외하고 표준오류 코드도 괜찮다고 생각함 2024. 3. 31. 아이템 5 - 예외를 활용해 코드에 제한을 걸어라 확실하게 어떤 형태로 동작해야 하는 코드가 있다면, 예외를 활용해 제한을 걸어주는 것이 좋다 아래에 몇가지 코드를 제시함 // require: 파라미터를 검증 fun acceptOnlyTwo(num: Int) { // 원하는것만 적는다 require(num == 2) { "2만 허용!" } // 원하는게 아닐경우를 적는다 if(num != 2) { throw IllegalArgumentException("2만 허용!") } } // check: 상태혹은 멤버 변수를 검증 class Person { val status: PersonStatus = PersonStatus.PLAYING fun sleep() { check(this.status == PersonStatus.PLAYING) { "에러 메시지!" .. 2024. 3. 31. 아이템 4 - inferred 타입으로 리턴하지 말라 타입 추론은 코틀린의 특징 중 하나 자바도 자바10부터는 코틀린을 따라 타입 추론을 도입함(물론 코틀린과 비교하면 몇가지 제약이 존재함) c# 은 3.0 부터 도입함 var 타입..2007년.. 타입 추론을 사용할 때는 몇 가지 위험한 부분들이 있다 할당 때 inferred 타입은 정확하게 오른쪽에 있는 피연산자에 맞게 설정된다 절대로 슈퍼클랫 또는 인터페이스로는 설정되지 않습니다. 코틀린의 타입 추론 과정에서 변수에 할당되는 구체적인 값의 타입을 기반으로 타입이 결졍되며, 이 과정에서 추상 타입(슈퍼클래스 또는 인처페이스) 은 타입으로 추론되지 않는 것을 의미. 즉 타입 추론은 가장 추제적인 타입을 선택 class Item4Test { @Test fun missMatchTest() { var anima.. 2024. 3. 31. 아이템 3 - 최대한 플래폼 타입을 사용하지 말라 코틀린에서는 null-safety 매커니즘으로 인해 NPE 를 거의 찾아보기 힘들다. null 관련 오류를 방지하기 위한 코틀린의 핵심 기능 중 하나 타입 시스템을 통해 null 참조를 엄격히 제어하여, 가능한 실행 시간 오류를 컴파일 시간에 잡아낼 수 있게 한다. 코틀린에서 변수를 선언할 때, 변수가 null 을 받을 수 있는지 아닌지를 명시적으로 선언해야 한다. 변수 타입 뒤에 ? 를 붙이면 그 변수는 null 값을 가질 수 있다고 선언하는 것 코틀린은 자바 등의 다른 프로그래밍 언어에서 넘어온 타입들을 특수하게 다룹니다. 이러한 타입을 플랫폼 타입 이라고 부른다. 자바와 코틀린 사이의 상호 운용성을 위헤 도입된 개념 코틀린은 자체적으로 nill 안정성을 엄격하게 관리하지만, 자바 코드는 코틀린처럼 .. 2024. 3. 31. 이전 1 2 3 4 5 6 다음 728x90