proposal: Go 2: Preference over snake case instead of camel case

[exapsy]

Go Programming Experience

Experienced

Other Languages Experience

Rust, NodeJS

Related Idea

• Has this idea, or one like it, been proposed before?
• Does this affect error handling?
• Is this about generics?
• Is this change backward compatible? Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit

Has this idea, or one like it, been proposed before?

In other languages, it's already a standard. In Golang, I'm not quite sure

Does this affect error handling?

Not at all

Is this about generics?

Nope.

Proposal

The proposal is to make it a standard to have Golang adhere to snake_case/Snake_case instead of camelCase/CamelCase.

Reason being:

• Okay, Golang does not have Enums. As much as anybody would love to call this "enums", it's not, its pseudo-enums

      type MyEnum int
      const (
              MyEnumOne MyEnum = iota + 1
              MyEnumTwo
      )

  It pollutes the namespace, it's not really intuitive, it does not have compiler support or anything of that short in case you want to validate an enum. You can only do that by inserting functions on the type itself and doing it by hand. Okay, my point is not to say how these are not enums, but how they pollute the namespace in such a way that it becomes unreadable. Imagine having a longNameForAnEnumOne and having to read all of that instead of just reading long_name_for_an_enum_one.

Snake case is designed to have underscores as a replacement for spaces. CamelCase is literally designed to stick letters onto each other. It's counter-intuitive when trying to read someone's code or your own code when snake case was designed for this specific purpose to be easily readable.

I've programmed in Rust before, and while Rust may not be itself the most readable language of them all, the variable or function names are more than suffice. C++ too, Python, or other languages that usually follow the snake_case format and for a good reason. Golang is one of the few that has stepped back and doesn't use snake_case and uses camelCase instead. I don't quite understand why, and why the linter tries to enforce you by placing warnings for auto-fixing it.

It's completely reasonable to try to enforce one code-style for name convention with linting don't misunderstand me. But it's counter-intuitive to try to enforce a code-style that is designed to not be as readable as its competitors.

And best of all, it's backwards compatible, it has nothing to do with the code itself or the compiler at all. You can still write in snake_case, it's just that the compiler and the IDE will complain, but your code will work it's not that it's against the principles of the compiler.

Language Spec Changes

No language spec changes. Just the philosophy that "everything should be written in CamelCase" and either leave some freedom on the programming team deciding the best convention, or enforce the one that is just ... objectively the best out there for naming convention. The one that is designed to be readable because it's designed to separate words with a "space"-like symbol.

Informal Change

No response

Is this change backward compatible?

Totally.

Orthogonality: How does this change interact or overlap with existing features?

It does not interact with any feature.

Would this change make Go easier or harder to learn, and why?

It makes it easier to read, write and maintain code or even write long pseudo-enums.

Cost Description

The linter would have to stop complaining or try to enforce snake_case instead at least.

Changes to Go ToolChain

No changes except that gofmt would probably have to enforce another naming convention.

Performance Costs

No performance cost, it's just naming convention

Prototype

Self-understandable what the prototype is or should be.
Instead of this

func MyLongNameFunction()

have this

func My_long_name_function()

[mpldr]

Maybe we could also migrate to spaces for indentation, because they have literally no advantage over tabs 👍 (/s if it wasn't obvious)

[exapsy]

Maybe we could also migrate to spaces for indentation, because they have literally no advantage over tabs 👍 (/s if it wasn't obvious)

Great way of making a constructive conversation, and so many arguments provided here. Thanks for the constructive criticism. /s if it wasn't obvious

[mpldr]

Sorry, I also find "it's unintuitive" not exactly an objective measure for anything. I myself can read and mentally parse a name just fine independent on if it's CamelCase, Snake_Case, Kebap-Case, or whatever someone may come up with. Do you have something "tangible"?

[mvdan]

This seems contradictory to Go's use of uppercase letters to export names in packages.

Moreover, I don't think we could actually switch the ecosystem of developers and existing code even if we wished to.

[qbit]

If it's not a comprehensive change (breaking backwards compat) - it will result in a split ecosystem where pre-snakeCase code is still camel and new code is snakeCase.. Now you have to live with camel and snake! Doesn't seem ideal.

[seankhliao]

As a style guide, this can be adopted outside of the standard library, and if proven popular, we can then consider a change.

[exapsy]

I find it constructive that yes indeed it would split as a pre-snake-case and after-snake-case, this is constructive criticism and a problem to discuss about.

Although, from what I see, the contribution community is rather aggressive to such a point to a point that it just literally insults my points by being sarcastic or ironic when I pointed out some serious points. So, I think the most serious problem here is that people just fear change. Just like with Generics, just like with any change on Golang's ecosystem, good or bad.

The "pre-snake-case" and "after-snake-case" argument while constructive, is not a serious concern. It's not a breaking-feature concern. We'll just make linters that auto-format to snake-case. When every other serious language has defaulted to snake-case, Golang has chosen to go with CamelCase and with name conventions such as "MarshalJSON" instead of "MarshalJson" which means if you wanted to have another known abbreviation near JSON, you would have something like "MarshalJSONBSON" (depending on the use case, its just an example), which is obviously impractical. Snake case is made ... to just solve these things by default and be readable.

So, I find that the issue is "not planned" more because people avert to change, rather than because it's not for the best.
At least, I would like to have the option to change to snake case if I wanted to, it's made to read things the easy way instead of sticking words to each other or have abbreviations stuck to each other.

edit:

It's natural that people avert to change, but people, do not try to convince me that CamelCase is more readable than snake_case. If you want to convince yourself that okay, but then read books with CamelCase instead of having spaces in between. InFactIWillMakeASentenceToProveMyCaseThatThisIsNotMadeToBeReadable. Period.

[mpldr]

when I pointed out some serious points

Correct me if I'm wrong, but your point was that it was hard to read for you.

When every other serious language has defaulted to snake-case, Golang has chosen to go with CamelCase

What is this supposed to express? This sound like a fallacy.

At least, I would like to have the option to change to snake case if I wanted to

You are free to do so. _ is a valid character in identifiers.

do not try to convince me that CamelCase is more readable than snake_case

Maybe I missed who said that… Still, reading code and preferences is a highly individual thing and as such the experience differs from developer to developer. You seem to have big issues reading camel_case, while apparently most of the people see no distinct advantage in using SnakeCase instead.

[exapsy]

Maybe I missed who said that…

1. let me remind you your own words, maybe you'll recall, where you used Irony and thus aggressiveness/toxicity just to make your point:

   Maybe we could also migrate to spaces for indentation, because they have literally no advantage over tabs 👍 (/s if it wasn't obvious)
   

2. Still, reading code and preferences is a highly individual thing and as such the experience differs from developer to developer

   ImadeMyPointInMyLastSentence. Is_that_sufficient_for you?

3. You are free to do so. _ is a valid character in identifiers.

You can, but the linter always complains and you split your team into the "snake_case" team and the "camelCase" team. Like, that was my point from the start, to have a standardized name convention. Instead you specifically chose to be sarcastic with me and act like a smartass.

[exapsy]

Use as many emoji reactions as you want. They're not arguments against your own toxicity, of the aversion to change of the community that I see in some people here who even have the badge of the contributor, and maybe hold a responsibility to be a little bit more friendlier, professional, and the aversion to change, and not really any arguments against what I proposed.

Just pure toxicity by being sarcastic with me, and emoji reactions .... great way to show what a friendly place for proposals this is, instead of providing actual arguments and having a friendly fruitful discussion. Like, I insulted nobody, yet people like you feel insulted because ... of a name convention?

• In all fairness, one person only provided an actual argument .. @qbit , but the "we'll split it between the camelCase team and the snake_case team" is not really the best argument.

  Like, same could be said about Generics that took 10 years to make because people of the community argued so much against them when its a so much useful future, and theyre finally here after so much fight for such a crucial feature, even if they're not really implemented the way in other languages is and they're much less efficient to use. Same could be said about Enums, a feature that is in almost every single modern language, and in Golang we just use pseudo-enums to be "simplistic" which pollute the namespace and are not compiler friendly. But then also we would split "the team between pseudo-enums" and actual enums. People Avert to change. I understand that. But it is not the best argument to use to make something better than it is, neither is to be sarcastic and toxic to people just because you dont like their arguments.

[mpldr]

let me remind you your own words, maybe you'll recall, where you used Irony and thus aggressiveness/toxicity just to make your point:

Yet I never said one was more readable than the other, quite the opposite. At least to me there is no notable difference. Including "ImadeMyPointInMyLastSentence. Is_that_sufficient_for you?" Which is a terribly weak argument if one can read it just fine :D

You can, but the linter always complains and you split your team into the "snake_case" team and the "camelCase" team

As the proverb goes "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.", and I think this applies here as well.

that was my point from the start, to have a standardized name convention

There is one, it's camel_case. At least that is the established standard. Seeing how there has not been a lot of agreement with you in terms of legibility, I think it's rather safe to assume that this is a "you" problem.

They're not arguments against your own toxicity, of the aversion to change of the community that I see in some people here who even have the badge of the contributor

You are certainly correct that my initial response was unreflected and has been a tad aggressive. This however, does not at all change the point that in my eyes the reasons given for a transition are not just very individual, but also have significant implications on the wider ecosystem that would arguably not be worth the tradeoff. One of the declared goals of Go is not to repeat the mess Python 2→3 has caused, and while only being stylistic, I think the snakeCase transition would hit a similar direction.

Like, same could be said about Generics that took 10 years to make because people of the community argued so much against them when its a so much useful future

I was not in favour or against it, but after seeing it, it's usefulness is limited. I have seen one usecase where it has been a perfect fit, and otherwise has only changed the location of the typeswitch. Though I have to admit that I was fortunately wrong and there was not nearly enough generic-abuse as I would've expected. I also completely agree about enums, but this has absolutely nothing to do with snakeCase.

Overall, I still think your provided arguments are rather weak and do not take into account some of the overall implications the transition would entail (including API breaks in pretty much every single stdlib package. Sure, Go2 is for just those, but see the point about the python debacle further up. This is not exclusively people being averse to change, but more that the perceived benefit in absolutely no way outweighs the cost of such a change.

but the linter always complains

Change your linter, my man. As far as I can see, the linter-light that comes with Go (go vet) doesn't care. Though I just gave it a quick try with a const.