This is another indicator that Go looks to really standardize its code. They have the format tool, path conventions, and now a post about naming packages. I appreciate their efforts as I think it will make third-party tools much more available to everyone who wants to use them.
That’s just how Rob Pike and the Bell Labs people like to do it. I buy the conciseness argument, but I think the one letter variable name thing must be vestigial from some limitation in early compilers. Anyone know?
I write my Go with a tad longer variable names. It took me a long time to track down that camelCase is the way to go. It’s not mentioned in the style guide because if your variable needs two words or disambiguation you’re doing it wrong. Instead they think you should split the function, etc.
Single variable names are pretty common in Haskell fwiw. I don’t have much issue with them. If the name is local in scope I don’t see much need for a hugely long name.
I would have to agree with the two word remark in principle but devil in the details and all.
In my experience it works just fine. It made it easier to figure out that some packages were out of place. More than a few level deep of nesting kinda shows that you need to reorganize the code, imho.
The particular example of “list” stuck out to me. It’s not at all obvious to me that list means a doubly-linked list; it could easily be a singly-linked list or an array-backed list. If I don’t care about the implementation of my list, then I guess just list is fine, but usually I do care, or at least I ought to make the decision on implementation. (And if I actually don’t care, it should almost certainly be array-backed, but that has no bearing on the immediate issue.)
I found the article to be very mixed between things I would find very annoying (like the underqualified list) and things that are very reasonable or that I hadn’t ever really considered (like avoiding “stuttering”/repetition in fully-qualified names).
This is another indicator that Go looks to really standardize its code. They have the format tool, path conventions, and now a post about naming packages. I appreciate their efforts as I think it will make third-party tools much more available to everyone who wants to use them.
I love how Go emphasises conciseness in package names. None of this com.company.appname.application.internal.lookupproduct horror.
That’s just how Rob Pike and the Bell Labs people like to do it. I buy the conciseness argument, but I think the one letter variable name thing must be vestigial from some limitation in early compilers. Anyone know?
I write my Go with a tad longer variable names. It took me a long time to track down that camelCase is the way to go. It’s not mentioned in the style guide because if your variable needs two words or disambiguation you’re doing it wrong. Instead they think you should split the function, etc.
Single variable names are pretty common in Haskell fwiw. I don’t have much issue with them. If the name is local in scope I don’t see much need for a hugely long name.
I would have to agree with the two word remark in principle but devil in the details and all.
[Comment removed by author]
In my experience it works just fine. It made it easier to figure out that some packages were out of place. More than a few level deep of nesting kinda shows that you need to reorganize the code, imho.
The particular example of “
list” stuck out to me. It’s not at all obvious to me thatlistmeans a doubly-linked list; it could easily be a singly-linked list or an array-backed list. If I don’t care about the implementation of my list, then I guess justlistis fine, but usually I do care, or at least I ought to make the decision on implementation. (And if I actually don’t care, it should almost certainly be array-backed, but that has no bearing on the immediate issue.)I found the article to be very mixed between things I would find very annoying (like the underqualified
list) and things that are very reasonable or that I hadn’t ever really considered (like avoiding “stuttering”/repetition in fully-qualified names).It would be weird not to use a slice if you wanted an array-backed list.
If you find this annoying in your code base, I think that’s a pretty good bad smell—that you’re fighting the language.