<div dir="ltr"><p dir="ltr">I have two guiding principles when coding:</p>
<p dir="ltr">Write the code that is idiomatic to the language it is written in.</p>
<p dir="ltr">Write code that is easy to read by someone new to the codebase, but comfortable with the language.</p>
<p dir="ltr">If we're telling war stories, at my last job we had an architect level developer who was new to python but very experienced in Perl. He wrote entire modules in Python just so he could write Python code that read more like Perl. Needless to say, his Python code was nearly incomprehensible to the devs familiar with Python.</p>


<p dir="ltr">Henning said the single letter variable names surprised him, but they would not surprise a developer who is comfortable with Go. It is standard practice in Go to use single letter variable names when the meaning is clear. This nearly always the case for the receiver for methods on types, and often the case for parameters to functions. This is shown in pretty much the entire Go standard library. For example: <a href="http://golang.org/src/pkg/image/geom.go?s=2380:2421#L98">http://golang.org/src/pkg/image/geom.go?s=2380:2421#L98</a></p>
<p>That being said, I think some of the std lib in Go is a little unreadable because of their choice of variable names, but I am also not as experienced in Go programming as the people writing the standard library :)</p><p>
On Mon, Aug 19, 2013 at 5:42 PM, Tim Penhey <<a href="mailto:tim.penhey@canonical.com" target="_blank">tim.penhey@canonical.com</a>> wrote:<br></p><p dir="ltr">
> On 19/08/13 20:52, Henning Eggers wrote:<br>
>> On 16.08.2013 13:11, Nate Finch wrote:<br>
>>> Personally, I prefer variables in the 1-4 character range, because they are<br>
>>> less prone to typos and I find them easier to read when embedded in complex<br>
>>> expressions.<br>
>><br>
>> That is something I was surprised to see in many places when browsing the juju<br>
>> go source. Abbreviations or even single letters for variable names are against<br>
>> what I have been taught and practiced as good software engineering over the<br>
>> last twenty years or so. The rule may be emphasized differently in different<br>
>> software projects but it really struck me as very lax in the juju source.<br>
><br>
> I do have to say I agree with Henning here.<br>
><br>
> It is my *strong* preference to have full pronounceable, meaningful<br>
> names.  IMO "information" is not meaningful (neither is "state")<br>
><br>
> As mentioned on our weekly call, all core developers please buy a copy<br>
> of "Clean Code" by Robert C. Martin, and expense it if you don't already<br>
> have a copy.<br>
><br>
> We are going to start doing a chapter by chapter review.<br>
><br>
>> Is there a coding style guide for go juju?<br>
><br>
> Not really.<br>
><br>
> Code should be written to be read by *humans*, not compilers.<br>
><br>
> Code will be read so much more than it will be written, and often by<br>
> people who aren't as familiar with the details or intricacies.<br>
> Meaningful variable names are a key component of good readable code.<br>
><br>
> Tim<br>
><br>
><br>
> --<br>
> Juju-dev mailing list<br>
> <a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a></p>
</div>