💾 Archived View for gemini.thorp.dev › posts › 2021-09-30-golang-naming-conventions.gmi captured on 2024-09-28 at 23:53:54. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-08-18)
-=-=-=-=-=-=-
_ . , .<[gemini.Thorp.dev]> .
* / \_ * / \_ _ * * /\'__ *
/ \ / \, (( . _/ / \ *'.
. /\/\ /\/ :' __ \_ ` _^/ ^/ `--.
/ \/ \ _/ \-'\ * /.' ^_ \_ .'\ *
/\ .- `. \/ \ /==~=-=~=-=-;. _/ \ -. `_/ \
/ `-.__ ^ / .-'.--\ =-=~_=-=~=^/ _ `--./ .-' `-
/jgs `. / / `.~-^=-=~=^=.-' '-._ `._
[Updated 2024-07-18] - Minor rewording
I've been working with Golang off and on since college. When I first
encountered the language I knew Java and C, and I was thrilled to be working
with a language that felt modern yet familiar. The language's opinions were
sensible but things like type-inference, simple concurrency, and duck-typing
were refreshing. I no longer feel this way
Nowadays when I encounter an opinionated decision in Golang's design or
prescriptive style, I disagree with it. Not just "I don't like this"
so much as "I don't understand how this could be a positive choice". The
example of this I want to talk about is actually a part of the
Go Official Style [1]: variable name casing.
Initialisms are, by Go's standard, consistently cased. So if you have a VOIP ID or
Target Group ARN you may write them as VOIPID and TargetGroupARN instead of
VoipID TargetGroupArn. This degrades the readability of the variables and the
ability to break the var into words. When you camel case initialisms you are
able to intuitively break up VoipId into VOIP and ID. This is more difficult
with VOIPID or voipid. God forbid you need to do so programmatically.
Without a dictionary of initialisms most programs would break the first example
into the words "V", "O", "I", "P", "I", and "D". Us humans have a dictionary
of initialisms in our brain, so all we need to do is try and figure out where
to place the delimeter.
Of course Golang has a solution for this: mix and match! Use lowercase for one
word and UPPERCASE for the next. Easy! voipID and VOIPid (in the case of a
public field) are easy and only come at the cost of inconsistent casing.
Of course this breaks down if you have more than two in a row.
VoipXmlId
VOIPXMLID
VOIPxmlID
voipXMLid
Since the casing of the first character in a function name controls function's
visibility, this adds even more weirdisms. In general Golang's variable casing
decisions to be ugly, so it's not necessarily a surprise. Still, this
particular choice seems unusually baffling.