Nim : Style insensitivity , snake_case , camelCase

camelCase is better to read, and it also results in smaller phrases (one less character). having everything in lower case is not ideal.

Nim : Style insensitivity , snake_case , camelCase

I don't agree but I also don't care enough to continue the discussion. Believe what you want, I know what I know. ;-)

Nim : Style insensitivity , snake_case , camelCase

> 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: I mean, have you read the paper you linked ? While the

Nim : Style insensitivity , snake_case , camelCase

I find camelCase easier to type

Nim : Style insensitivity , snake_case , camelCase

please, boss, no more trolling...

Nim : Style insensitivity , snake_case , camelCase

> I found the claim this is objective unfounded and I strongly suspect this is > a cultural thing. Nope, see here:

Nim : Style insensitivity , snake_case , camelCase

> 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).

Nim : Style insensitivity , snake_case , camelCase

[spam]: I put together a linter that can switch naming style automatically: Interestingly, most people I know find snake_case more readable and they are not German speakers.

Nim : Style insensitivity , snake_case , camelCase

Oh, I did a dumb. Sorry.

Nim : Style insensitivity , snake_case , camelCase

thats kebab-case

Nim : Style insensitivity , snake_case , camelCase

I'd say `snake-case` is the most readable, since that's precisely what hyphens are for in English — joining multiple words into a single one.

Nim : Style insensitivity , snake_case , camelCase

I did not think of German making camel case easier to read. Even if capital letters are misleading to you though there are not many better alternatives. I don't know how Python would look with camel case but if you try snake case on Nim it does not look very good. I think it's the combination

Nim : Style insensitivity , snake_case , camelCase

Your point about cultural differences and capitals/compounds is a good one, but speaks to ease of /parsing/ identifiers. I think the point was that separating words visually makes it harder to lex them into a single semantic unit.

Nim : Style insensitivity , snake_case , camelCase

> I think consts should be lowercase, since you might want to turn them into a > variable/letiable later if the need arises and that way you'll be able to do > it without having to rename them. If you're converting a constant, most of which are usually global, to a variable, the name is the

Nim : Style insensitivity , snake_case , camelCase

I think consts should be lowercase, since you might want to turn them into a variable/letiable later if the need arises and that way you'll be able to do it without having to rename them.

Nim : Style insensitivity , snake_case , camelCase

We've started enforcing the use of `--styleCheck:usages` the moment it landed in the compiler - ie we don't allow using different style on use than the declaration: in secure software, using different styles is a good way to sneak in unexpected identifiers that don't look similar at a glance,

Nim : Style insensitivity , snake_case , camelCase

I see, I didn't read that part. From my very limited experience I get the feeling that I would like at least the internal consts to be consistent, so it's easier to remember. I think I understand the idea to be flexible about uppercase here, in case some people want to use ALLCAPS consts.

Nim : Style insensitivity , snake_case , camelCase

That "NEP" was accepted long ago and it's the official style guide. And it says: > All other identifiers should be in camelCase with the exception of constants > which **may** use PascalCase but are not required to. So the consts in system.nim adhere to the style guide. What do you think

Nim : Style insensitivity , snake_case , camelCase

I'm a newcomer to Nim and also more or less a refugee from Python. After initially balking at the case-insensitivity stuff, I've found that it is not really a problem, except for one small annoyance. Because of case-sensitivity of the first letter, I naturally started leaning towards using

Nim : Style insensitivity , snake_case , camelCase

Here's a proof-of-concept Vim script that changes `snake_case` to `camelCase` when the cursor is on a different line. setlocal conceallevel=2 for i in range(1, 26) let upper = nr2char(64 + i) let lower = nr2char(96 + i) execute 'syntax match nimUnderscoreLetter

Nim : Style insensitivity , snake_case , camelCase

I take this as a challenge to make a Vim plugin that does exactly that.

Nim : Style insensitivity , snake_case , camelCase

One argument that hasn't been mentioned before. Given the right editor plugin, code that is really `fooBar` can be **rendered** as `foo_bar` (and vice versa). And Nim is the only language where that can be done reliably (which explains why such plugins are not yet common) as the exact spelling

Nim : Style insensitivity , snake_case , camelCase

Is it already the time of year of the threads complaining about things that aren't actually a problem ? Should I go ahead and open the thread about how curly braces are better for people coming from C than indentation ?

Nim : Style insensitivity , snake_case , camelCase

I am _this close_ to close this thread. If only Nim used snake case it would be "much easier" to come from Python. And if that wish is granted, if only Nim used Python's syntax for list comprehensions. And if that wish is granted, if only Nim used `def` for functions. And if that wish is

Nim : Style insensitivity , snake_case , camelCase

It's unfortunate that we have a feature whose purpose is to avoid bikeshedding over naming conventions, but people are still bikeshedding over naming conventions.

Nim : Style insensitivity , snake_case , camelCase

> Nim and Python may look similar, from a distance. But both are very > different. I think Nim is closer to DLang, C++, Rust, Go than to Python. Nim being similar to Python is a selling point. I don't see why so many are eager to make it seem like Nim and Python aren't alike. There are far more

Nim : Style insensitivity , snake_case , camelCase

The naming conventions are really unlikely to be the deciding factor between a Python programmer feeling at home with Nim vs. not. Nim is already a language that enables code to be written in whatever convention you like in your own projects, so just write it how you want and stop trying to

Nim : Style insensitivity , snake_case , camelCase

I think both languages have bigger problems than `fooBar()` Vs `foo_bar()` anyways...

Nim : Style insensitivity , snake_case , camelCase

> For what it's worth, I agree that Nim and Python are very alike. Nim and Python may look similar, from a distance. But both are very different. I think Nim is closer to DLang, C++, Rust, Go than to Python. In the past some people thought that Nim is just a faster Python, and most of that

Nim : Style insensitivity , snake_case , camelCase

You can skip the underscores too:

Nim : Style insensitivity , snake_case , camelCase

Oh sorry, I didn't intend it as a personal attack. After all I don't know you at all so that would be rather hard to do even if I wanted to. But complaining about readability and style standards in text which doesn't follow the style standards of English which makes it exceedingly difficult to

Nim : Style insensitivity , snake_case , camelCase

> Reading and Writing nim is almost like python , similar standard library and > many language features form python and its good , why people so defensive > about it here? For what it's worth, I agree that Nim and Python are very alike. But I don't think snake_case should be the default

Nim : Style insensitivity , snake_case , camelCase

@v3ss0n I think your example is not very realistic for neither Python nor Nim. It would be: vhost.generate() vhost.list() vhost.update() vport.generate() vport.list() vm.start() vm.stop() Run For both languages. Or some shorter version in Nim

Nim : Style insensitivity , snake_case , camelCase

I would pick the second due to : easy to group related functions by uppercase letters can easily see group of related functions at a glance. style is already set, but you are free to use whatever style you want.

Nim : Style insensitivity , snake_case , camelCase

> white-spaced language , iterator , generators , those are all python features > that pythonists loves and still nim is not like python

Nim : Style insensitivity , snake_case , camelCase

If you learn other statically typed programming language like C++/D/Rust etc, you would find Nim is actually closer to them rather than Python. Nim code is just looks like Python rather than C++/D/Rust because Nim don't use `{}` to make a block and doesn't require `;` in an end of line. Some

Nim : Style insensitivity , snake_case , camelCase

What? Nimgrep supports it via its `-y` switch. Since a decade or so...

Nim : Style insensitivity , snake_case , camelCase

> 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.

Nim : Style insensitivity , snake_case , camelCase

Python wont have Style insensitivity, thats the reason I have to use C++ names in PyQt ...

Nim : Style insensitivity , snake_case , camelCase

That would be `styleCheck:usages`, new in 1.6, I think?

Nim : Style insensitivity , snake_case , camelCase

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? Or even in your own project, but not necessarily the same as it was in the original definition? I sometimes mess up my casing, and while it

Nim : Style insensitivity , snake_case , camelCase

Nim is NOT like python...

Nim : Style insensitivity , snake_case , camelCase

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

Nim : Style insensitivity , snake_case , camelCase

> 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) Run with myFooBar = await otherBazStuff(oneThing, anotherThing) Run

Nim : Style insensitivity , snake_case , camelCase

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