Clear is better than clever [pdf]
Nice intro, which then jumps to an absolutely arbitrary (for someone who hasn&#x27;t coded in Go) set of recommendations, which are (imo) poorly argued from the perspective of clarity. Especially the case of &quot;var person int&quot;, how is it cleaner than &quot;var person int = 0&quot; - and why are we even talking about zero values when the variable was not supposed to be intialized. Many decent imperative languages let you not intiialize a variable, and then not allow you to reference it until it&#x27;s been initialized in all branches.<p>Mant things are left on the table. First of all, the audience. If you&#x27;re explaining something to someone, you must consider the audience to be successful. So are we writing code to be read by Go experts? Go noobs? Software Engineers with general background in many lanaguages, but perhaps not go? Noob programmers? You want to assume the lowest level of understanding that is imaginable, and that&#x27;s probably the last but one I listed in corporate environment.<p>Now that you have your audience, you gotta wrestle with some high level issues that then trickle down to concrete code. Explicit over implicit. Purity over mutable state. Small code units over monolithic code units. DRY. Verbose naming (that doesn&#x27;t violate DRY). You gotta agree on the right level of code documentation - especially important for anything that resembles library code (or is an &quot;abstraction&quot;).<p>The hard parts (like good naming) are not Lintable (of course Lint anything you can, use auto-formatter etc.), they are cultured through countless interactions between people in your organization. Getting third opinions is a valuable method here.