Golang short names


(Eric Lindblad) #1

From J.K. Ousterhout’s © 2018 volume on Software Design.

Names for variables, methods and other entities.

The book’s examples are different than those in the therein cited (2014 circa) slides of A.G.

Do new Golang coders have difficulty with the use of short names?

book

single-letter variable names

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
}

longer names

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
}

slides

Bad

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

Good

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

A consensus between the two authors.

A rule of thumb (appearing on slide 4)

The greater the distance between a name’s declaration and its uses,
the longer the name should be.


(Dan Waters) #2

I am a fairly new Go programmer, and i have found i use short names for For statements or quick calculations, a holding variable or something like that. If i am using it more than once, or passing it between functions, etc. I will give it a more meaningful name. I have read other people’s code on Git that use short names, and have no idea what the variables are.


(Holloway) #3

More of idiomatic preference under one rule: As long as I do not need to refer another document/source code for acronym list. So to me:

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

and this:

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

are merely opinionated. The top one is guarded with an over-killed self-explanatory style while the bottom one is understandable as well.


One thing to note that for Public functions, it is always good to name the return value so that they get published in go doc. E.g.:

// RuneCount is to do something that count against a given buffer slice.
func RuneCount(buffer []byte) (count int) {
    for i := 0; i < len(buffer); {
        if buffer[i] < RuneSelf {
            i++
        } else {
            _, size := DecodeRune(buffer[i:])
            i += size
        }

        count++
    }

    return count
}

go doc output:

func RuneCount(buffer []byte) (count int)
    RuneCount is to do something that count against a given buffer slice.