CamelCase should lowercase first word
magiconair opened this issue · 8 comments
After looking of the output of #1 I think the solution is not elegant albeit technically correct.
More elegant names would be
TCPConn -> tcpConn
ID -> id
TCell -> tCell
...
I think CamelCase with upper=false should lowercase the first word and not just the first rune to generate prettier names.
What do you think?
I never understood why programmers lowercase abbreviations. The reason why we uppercase letters from an abbreviation is to clearly identify their nature (without dots). By forcing the casing of the first letter, you lose this context, but only on the first. How else would you know whether to read "abcThing" as either "ABC thing" or "abc thing"?
The first word is the first letter, and the first letter only.
I guess the context matters since it is not about lowercasing abbreviations but to distinguish words without the dots. In CamelCasing only the first letter of a word is upper-cased to show the word boundaries. We make an exception for abbreviations like ID and TCP but we should treat them as exceptions for lower-casing as well.
Simply because we would never define a private variable tCPConn. It would always be tcpConn for readability. Since we are using this library for generating Go variable names this matters.
Also, lowercasing only the first letter removes the context of this being a TCP connection. Is this t CP Conn? What is CP?
Abbreviations are an exception which you're already handling for the upper-case case. (https://play.golang.org/p/riP-voXz5RU). It would be consistent to also treat them as an exception for the lower-case case.
What is
CP?
CP is exactly what it looks like: an abbreviation.
We can recover the forced case with one assumption: single letters are abbreviations. If name.Delimit(s, ' ') gets that both "tCPConn" and "TCPConn" are "TCP conn", then so can we. Otherwise, is "sunFee" a "sun fee" or a "SUN fee"?
https://github.com/pascaldekloe/jwt/blob/v1.10.0/jwt.go#L117
If you want to drop more context (and make the reader guess), then the algorithm is easy. Start reading on the second rune. As long as it is uppercase: lowercase the previous and continue with the next one.
But CP is not an abbreviation. It is a part of an abbreviation. The algorithm split one word into two.
I'm not arguing that the algorithm isn't correct but I think it is not producing useful results for private Go identifiers and that there are other ways which are correct as well.
Every uppercase followed by another uppercase (with CamelCase) is an abbreviated word. Transmission CP is a perfectly valid expression. Again, if name can see that tCP belongs as one then so can you. Why the resistance? I'm arguing that Go developers should write variables like name does. The results are very useful.
Go adviced developers to stop writing "Id" and "Tcp", which is wonderful. They failed by stating that "tcp" at the beginning is an exception. It is not. It took me some time too.
The "aBCThing" option doesn't look right.
I don't agree but lets leave it at that.
Your argument is technically correct in that it follows the rules by the letter but not in spirit of providing readable identifiers.
I would never name a variable tCPConn since this means doing it to satisfy the language and the compiler instead of the developer. Code is meant for humans to understand and I doubt that anybody else would name a variable like this.