Since when are variables names a language issue?
There is no such thing as "Java length like names", or whatever. There are good practices and bad practices and they are universal.
There is no such thing as "Java length like names", or whatever. There are good practices and bad practices and they are universal.
I happen to be learning Go coming from a C background. I find "The Go Programming Language" by Donovan and Kernighan exemplary and the decades of experience that went into the language really show.
If you look past the book, and directly at the STL, you'll find a common example: the "fmt" library, shortened to save three letters. Or compare the verbosity of these two examples from language docs, and the length and descriptiveness of variable names in them: https://docs.oracle.com/javase/tutorial/essential/io/cl.html to https://golang.org/pkg/bufio/#example_Scanner_emptyFinalToke...
I agree, it's a great language. These naming conventions are part of its developers and community.
There is no issue with having short names to describe well-known entities part of the language, or trivial code.
Your example from pkg.bufio is trivial and but still the variables names are meaningful. There is a difference between clearly and meaningful, and verbose.
Your example from Java is not very different.
I feel that the point is not being understood here.
If there was one true way to do it, everybody would adopt it (unless you consider some communities are just plain dumb).
> 2.1. Choose identifiers for clarity, not brevity
Cosmetic considerations like snake or camel case are irrelevant.
The advice above is standard good practice that is not dependent on the language used.
First off, OP is talking about a trend in the community to favor shorter and shorter names. He didn't say you need to code that way, but there is an increasing chance that the programmers you work with, or the libraries you depend on, will have adopted this convention.
Second, unless you are coding in a vacuum or starting a brand new project, you're usually expected to follow the conventions of an existing codebase. These were likely influenced by conventions in the community, which often are set by conventions in the standard library, which have much to do with the language.