1. 8
  1.  

  2. 5

    Personally, my career has been filled with picking up people’s projects and either;

    • Making them work as originally intended
    • Shipping new features
    • Reversing large code bases with no documentation

    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.

    https://developer.apple.com/library/mac/samplecode/SerialPortSample/Listings/SerialPortSample_SerialPortSample_c.html#//apple_ref/doc/uid/DTS10000454-SerialPortSample_SerialPortSample_c-DontLinkElementID_4

    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.

    • We agree that we won’t name call
    • We agree that won’t subvert each other’s authority with our kids
    • We agree that we will discuss financial purchases over (N) amount
    • etc

    Which leads me to my (what I hope) fairly pragmatic philosophy.

    • If I am the Lead Engineer I’ll ask what the team wants to do.
    • My vote is that descriptive names are required and that the code base will be maintained with that requirement (code reviews, pairing, etc)
    • If I get out voted here, I’m ok with that. As long as the concession is that we consistently keep the agreed upon coding style (If some new “Code Ninja” is hired, they do not get to come in and be “Billy Bad-Ass” and change our conventions)

    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.

    1. 4

      Russ Cox responded on the golang mailing list about this:

      https://groups.google.com/forum/m/#!topic/golang-dev/CGGiLKunggo/discussion

      1. 2

        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.