As you mention, Nim is style insensitive. This means you can mix styles, which mostly comes in handy when importing a library from someone else and you want to use your own style. More often than not in my Python projects I would have imported two different libraries following different style-guides, and my code ended up as a hodge-podge of different casing rules. This is not the case in Nim, you can write a library using snake_case, and I can import it into my own project which uses camelCase without any issues.
NEP-1, the Nim style guide, favours camelCase: https://nim-lang.org/docs/nep1.html. So most Nim code is written in camelCase.
Now taking about style standards and readability, you might want to look over your post and fix the myriad of spacing issues around commas, periods, and question marks. Not to mention spelling and capitilisation mistakes, along with run-on and incomplete sentences.
For me and most of python devs, snake_case is a lot cleaner.
I think it's objectively worse. Compare
my_foo_bar = await other_baz_stuff(one_thing, another_thing)
with
myFooBar = await otherBazStuff(oneThing, anotherThing)
While it is easier with my_foo_bar to make out the words it consists of, it makes lexing the code in one's head much harder. The overall readability decreases with underscores.
Also consider using styleCheck:usages for big projects, the Nim compiler itself already uses more stricter style check: --styleCheck:error which enforces nep1.
The style checking of the compiler now supports a `--styleCheck:usages` switch. This switch
enforces that every symbol is written as it was declared, not enforcing
the official Nim style guide. To be enabled, this has to be combined either
with `--styleCheck:error` or `--styleCheck:hint`.
Would it be possible to have a --styleCheck:coherent or something which ensures that you use the same style for the same identifier in the same module?
I think it is styleCheck:usages which is new in 1.6 as @araq said.
[spam]: I put together a linter that can switch naming style automatically: https://github.com/FedericoCeratto/nimfmt
Interestingly, most people I know find snake_case more readable and they are not German speakers.
Interestingly, most people I know find snake_case more readable and they are not German speakers.
How do you know they don't merely claim to find it "more readable"? ;-) I mean, plenty of people also claim they are productive with Vim (and they are not).
I found the claim this is objective unfounded and I strongly suspect this is a cultural thing.
Nope, see here: http://www.cs.loyola.edu/~binkley/papers/icpc09-clouds.pdf
plenty of people also claim they are productive with Vim (and they are not).
Ah yes the good old "I'm not productive with it so no one is". Very compelling.
Nope, see here: http://www.cs.loyola.edu/~binkley/papers/icpc09-clouds.pdf
I mean, have you read the paper you linked ?
While the result are slightly in favor of camelCase, it is extremely biased (and they even said so themselves) and linked to another paper stating the opposite in the introduction (see citation [6]).
The result are based on a training set of 135 "experience programmer" : over half had less than 2 years experience, all of whom are English speaker. They only test for correctness (which isn't an issue with auto-completion) and find time (IDE highlight search pattern for you) so both criteria are not really relevant to anyone using a proper editor.
Generalizing the result based on such weak evidence is just intellectually dishonest ; for all we know the university that conducted the study teach people Java and so camelCase has better result.
In reality, it doesn't matter ; what matters is consistency across your code base - whether it's snake_case or camelCase makes very little difference once you're used to it. snake_case / camelCase are not going to be the reason a project is successful or not. Being consistent in the code you write, is.