상태를 정의할 때는 변수와 프로퍼티 스코프를 최소화 하는것이 좋음
최소화하지 않으면 아래와 같은 단점이 있다.
- 프로그램을 추적하고 관리하기 쉬워짐.
- 스코프 범위가 너무 넓으면 다른 개발자에 의해서 변수가 잘못 사용될 수 있음.
- 프로그램을 읽고 이해하기에 어려워짐
변수는 읽기 전용 또는 읽고 쓰기 전용 여부와 상관없이 변수를 정의할때 초기화되는 것이 좋다.
여러 프로퍼티를 한번에 설정할 경우에는 구조분해 선언을 활용하자
프로퍼티보다는 지역 변수를 사용하는 것이 좋다
캡처링에 유의하자.
val primes : Sequence<Int> = sequence {
var numbers = generateSequence(2) { it + 1 }
while(true){
val prime = numbers.first()
yield(prime)
numbers = numbers.drop(1)
.filter { it % prime != 0}
}
print(prime.take(10).toList())
}
위 코드는 반복문안에 prime 이 선언됐고
아래 코드는 반복문 밖에 prime 이 선언됐다
val primes : Sequence<Int> = sequence {
var numbers = generateSequence(2) { it + 1 }
var prime : Int // 여기에서 선언 된걸로 바뀐 상황
while(true){
prime = numbers.first()
yield(prime)
numbers = numbers.drop(1)
.filter { it % prime != 0}
}
print(prime.take(10).toList())
}
한번만 선언하고 while 안에서 값만 바꿔주면 더 좋지 않을까? 라고 생각 할수도 있겠지만
이는 의도치 않은 오류를 불러온다.
필터링은 시퀀스를 사용하기 때문에 나중에 실행되는데, 모든 스텝에서 점점 필터가 체이닝 되는데 위 코드에서는 항상 변경 가능한 prime 을 참조하게 된다. 따라서 항상 가장 마지막의 prime 값으로만 필터링 된 것
반응형
'Effective Kotiln' 카테고리의 다른 글
[이펙티브 코틀린] 7. 결과 부족이 발생할 경우 null과 Failure를 사용하라 (0) | 2023.03.01 |
---|---|
[이펙티브 코틀린] 5. 예외를 활용해 코드에 제한을 걸어라 (0) | 2023.01.18 |
[이펙티브 코틀린] 4. inferred 타입으로 리턴하지 말라 (0) | 2023.01.15 |
[이펙티브 코틀린] 3. 최대한 플랫폼 타입을 사용하지 마라 (0) | 2023.01.13 |
[이펙티브 코틀린] 1. 가변성을 제한하라 (0) | 2023.01.08 |