While I sympathize with the avoidance of "clever" code, it's worth pointing out that there is an opposite direction: don't re-implement standard abstractions.<p>There are many standard abstractions that it is safe to assume that literally everyone qualified to touch code will know. If they don't, your priority should be either replacing them teaching them, not replacing the code.<p>Different languages and paradigms have different examples of such abstractions, but a trivial example is loops:<p><pre><code> while(i < itt.length)
x = itt[i]
i = i + 1
for(i=0;i<itt.length;i++)
x = itt[i]
foreach(x in itt)
</code></pre>
There is a decreasing amount of mental overhead in reading each one of those, because I know what a foreach loop does, and I don't need to be on the lookout for strange behavior.<p>IMO, Go overcorrects on the "don't get clever" ideology to the point of needlessly increasing the amount of mental overhead required to read some code. The entire language was designed to solve a problem that should have been solved at the hiring level.
> think for thyself<p>Ok.<p>> Resist the temptation to be creative, stylish, or (worst of all) clever.<p>I've spent a good chunk of my career coming in and cleaning up and optimizing codebases, avoiding complete re-writes . Coming across a genuinely clever and novel approach to a tricky problem that someone else wrote is something I enjoy immensely.<p>I'm tired of hearing from the "is unneeded complexity" bandwagoners. There is a difference between clever and convoluted. I'll trade a few more minutes of grokking for more performance, less boiler plate, etc, all day.<p>That and in my experience with large codebases, most time spent understanding code is spent on the business logic anyway.
Boring, repetitive code should be generated. Devs are a lot more expensive than compilers, and bored devs start seeing patterns that aren’t quite there.