[A Philosophy of Software Design] chapter 14. Choosing Names

개요

네이밍을 하는 것은 소프트웨어 설계 관점에서 매우 저평가 되고 있다. 잘된 네이밍은 하나의 문서와도 같다. 이것을 통해서 코드 이해가 쉽고 버그를 쉽게 찾을 수도 있다.

하나의 네이밍 전체적인 시스템 복잡도를 올리지 않을 수 있다. 하지만 전체 시스템은 몇천개의 변수가 존재하며 좋은 네임을 선택하는 것은 관리 능력에 있어서 엄청난 영향을 줄 것이다.

14.1 Example: bad names cause bugs

os 시스템을 만들어서 사용해서 운영한 적이 있다. 그 과정에서 disk에 정보가 모두 0로 바뀌는 버그가 있었다.

6개월이라는 긴 시간동안 버그를 찾아봤더니 결국 네이밍 이슈였다.

block 이라는 것을 다른 값을 가지는 경우에서 사용하게 되었기 때문이다.

하지만 버그가 있는 코드를 여러번 읽었지만 당연히 올바른 값이 들어있을 것이라고 추측하게 되어서 찾아내지 못했다.

14.2 Create an image

이름을 만들어 내는것은 해당 기능, 역할에 대해서 코드를 읽는 리더의 입장에서 생각해보는 것이다. 좋은 이름은 많은 정보와 근본적인 개념을 제공해준다.

이름을 만들고 자기에게 물어보아라. 만약 주변 코드도 없고 선언도 모르며 문서도 없는 독립적인 환경에서 읽어도 이해가 되는지를 말이다.

이름은 추상화이다. 그것은 여러 개념들을 간략하게 해서 제공해준다. 이름을 통해서 중요하지 않은 것을 빼고 중요한 것에만 집중하고 알 수 있게 해준다.

14.3 Names should be precise

Red Flag: Vague Name If a variable or method name is broad enough to refer to many different things, then it doesn’t convey much information to the developer and the underlying entity is more likely to be misused.

Red Flag: Hard to Pick Name If it’s hard to find a simple name for a variable or method that creates a clear image of the underlying object, that’s a hint that the underlying object may not have a clean design.

14.4 Use names consistently

항상 일치성을 제공해줘야됨. 그렇지 않으면 같은 변수여도 다른 변수로 인식하게 되어서 인지 부조하를 만듬.

• 요구사항
  1. 첫째, 주어진 목적에 항상 공통 이름을 사용합니다.
  2. 둘째, 주어진 목적이 아닌 다른 목적에 공통 이름을 사용하지 마십시오.
  3. 셋째, 이름이 있는 모든 변수가 동일한 동작을 가질 수 있을 정도로 용도가 좁아야 합니다.

14.5 A different opinion: Go style guide

go style

func RuneCount(b []byte) int {
    i, n := 0, 0
    for i < len(b) {
        if b[i] < RuneSelf {
           i++ 
        } else {
            _, size := DecodeRune(b[i:])
            i += size 
        }
        n++ 
    }
    return n 
}

normal style

func RuneCount(buffer []byte) int {
    index, count := 0, 0
    for index < len(buffer) {
        if buffer[index] < RuneSelf {
           index++
        } else {
            _, size := DecodeRune(buffer[index:])
            index += size
        }
        count++ 
    }
    return count
}

go 언어는 짧은 변수명 사용을 권장한다.

첫번째는 go 스타일, 두번째는 그냥 일반적인 경우이다.

내가 생각하기에는 두번째 스타일이 조금 더 낫다고 생각한다. 명확하기 때문에.

만약 코드를 읽는 사람이 조금 더 명확하게 하기를 원한다면 그것을 따르는 것이 좋을 것 같다고 생각한다.

14.6 Conclusion

잘 선택된 이름은 코드를 이해하는데 엄청난 장점이 있습니다.

좋은 이름을 사용하는 것은 투자마인드로 매우 좋은 효과를 볼 것이다. 조금 더 노력해서 투자를 한다면 나중에 더욱 큰 이득을 볼 것입니다.

그 뿐만 아니라 이런 노력을 통해서 숙달이 된다면 공짜로 이런 이득을 볼 수 있습니다.