I'm learning Go as my first programming language, and I keep running into the choice between compact one-liners and more verbose, step-by-step code. For example, to select a random element from a slice, I might write:
func pickRandomFrom(items []string) string {
length := len(items)
index := rand.Intn(length)
return items[index]
}
Alternatively, I could write the operation inline:
item := items[rand.Intn(len(items))]
The longer version feels more readable to me because the helper has a descriptive name and I don't have to mentally unpack nested parentheses. However, it also introduces temporary variables, and I've seen people argue that similar code is less readable than a concise expression.
Programming advice often says to prefer clear code over clever code, but then makes exceptions for idiomatic code. Is there a useful rule of thumb, style guide, or reading recommendation for deciding when to keep an expression inline and when to break it into multiple lines or a helper function?
5 Answers
Give names to meaningful concepts, but don't create names for things that are already obvious. `length := len(items)` doesn't add much because `len(items)` clearly communicates what it is. A better middle ground would be something like `randomIndex := rand.Intn(len(items))`, followed by `return items[randomIndex]`. When in doubt, split things up, but avoid turning every tiny operation into its own step.
Multiple lines can make debugging easier. You can inspect intermediate values, set a breakpoint on a specific operation, or add temporary logging without restructuring a complicated expression. I might leave a simple library call inline, but if nested calls could produce a bug, I usually assign the result to a named variable.
Exercises often encourage compact solutions because the code is short-lived and people are experimenting with language features. Production code has different priorities: it should be easy to review, maintain, debug, and modify. The best general rule is to aim for one clear idea per line and avoid both dense clever expressions and unnecessary verbosity.
There isn't a strict rule. A one-liner is fine when it performs one obvious operation and can be understood immediately. Breaking it into several lines is also perfectly reasonable, especially if it makes the intent clearer. In this example, the extra lines are not a performance concern, so readability should drive the decision.
The important test is how easily someone can understand it months later, not just whether it makes sense while you're currently writing it. Sometimes five clear lines are better than one dense line, and sometimes the opposite is true.
A helper function is worthwhile when the operation has a useful name, is repeated, or represents a concept that makes the surrounding code easier to read. Calling `pickRandomFrom(deck)` can communicate intent better than repeating the indexing expression throughout the program. Don't add a helper solely to avoid typing a short expression once, though.
That is a practical advantage I hadn't considered. Being able to inspect the intermediate value is often worth the extra line.