Personally, my career has been filled with picking up people’s projects and either;
As such, I tend to error on the side of verbosity when naming things. Because I’ve been burned by poor/no conventions in the past. Which has cost me time and money.
What struck me is that Michael’s examples look a lot like Apple’s Cocoa code examples.
And given this, it continues to prove that there are different schools of thought about how to approach these conventions (obviously).
On a personal note. My wife and I have been to marital counseling several times. We always come away with more tools than when we started. Some conventions that we have agreed to.
Which leads me to my (what I hope) fairly pragmatic philosophy.
At the end of the day, you are “married” to the programmers on your team. And your code base is your beautiful and loving child. Conventions are simply communications tools for programmers to manage their family and raise that perfect (har, har) child.
As such, you are free to pick what works for you and your team, compromising with your team mates on any disagreements. But consistency is key.
Russ Cox responded on the golang mailing list about this:
I really just got to the nn section and read through the code. I’m familiar enough with that sort of logic that what nn did was obvious. If ‘nn’ was totalBytesWritten and ‘n’ was bytesWritten, I’d be wondering if bytesWritten shouldn’t be: bytesJustWritten or some other such long but not too long name.
With n and nn I know what n is “the size of the buffer I just wrote” and nn is “the running total of the buffers written up until success or error”. Both of those concepts are short enough for a comment, but too long for variable name. In a way the brvty makes the entire thing much clearer by removing the semiotics of English from the symbol and the symbolized. If you get my drift.