On 19 August 2013 22:42, Tim Penhey <[email protected]> wrote: > On 19/08/13 20:52, Henning Eggers wrote: >> On 16.08.2013 13:11, Nate Finch wrote: >>> Personally, I prefer variables in the 1-4 character range, because they are >>> less prone to typos and I find them easier to read when embedded in complex >>> expressions. >> >> That is something I was surprised to see in many places when browsing the >> juju >> go source. Abbreviations or even single letters for variable names are >> against >> what I have been taught and practiced as good software engineering over the >> last twenty years or so. The rule may be emphasized differently in different >> software projects but it really struck me as very lax in the juju source. > > I do have to say I agree with Henning here. > > It is my *strong* preference to have full pronounceable, meaningful > names. IMO "information" is not meaningful (neither is "state")
http://en.wikipedia.org/wiki/Information_content In particular "the amount of self-information contained in a probabilistic event depends only on the probability of that event: the smaller its probability, the larger the self-information associated with receiving the information that the event indeed occurred". (For those that haven't seen it, I tend to agree with this: http://research.swtch.com/names ) Global names are relatively rarely used in general, and hence have a higher associated information content (there are some exceptions, which is why we're happy with "gc" as a synonym for "gocheck", for example). In many places in Go, you can find out all that's useful about a name by looking a few lines up in the source code to find its type, or by a single click to find out the return type of the function that was called to define the function. Where the scope is larger, I entirely support longer variable names. But when you have: ctx := coretesting.Context(c) and "ctx" is only used in local scope, I don't see that the name carries much information (in the technical sense), or that naming it "context" helps code readability. For local variables, I think abbreviations make sense because that way they are more obviously local names when you see them in the source code - I am never going to name a function "ctx", but I may well name a function or package "context". I hope we don't end up in a place where people get called out for using "i" instead of "index" as loop variable. > As mentioned on our weekly call, all core developers please buy a copy > of "Clean Code" by Robert C. Martin, and expense it if you don't already > have a copy. Done. cheers, rog. -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
