[Branch ~go-bot/juju-core/trunk] Rev 1666

[roger peppe]

On 19 August 2013 22:42, Tim Penhey <tim.penhey at canonical.com> 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.