[Symmetry]

I've come to increasingly accept it over time? I mean, I'd really like it if my_function() and myFunction() just weren't allowed in the same section of code but if you allow the user to have both it's probably better that they refer to the same function than different functions.

[tryptophan]

It is a strange feature but it does have a good underlying idea.

Why would having two functions, named makeFile and make_file in the same program ever be a good idea?

Think of it as less of a language syntax feature and more of a code style enforcement paradigm.

Good lsp support makes it mostly fine imo.

[isofruit]

Imo it goes beyond that. You have folks from Java etc. coming over with their camel-case as well as python folks with snake-case. Now despite both of them writing in their own styles, their code can interact, because when the java-programmer gives you a `validateObject` procedure from their package, the python developer can just use it as `validate_object`.

Not being forced into other people's style choices is a really nice boon to me.

[thom]

It's not so much that anybody thinks that mix is a good idea, but it's just what happens immediately in any C/C++ codebase if you're using any nontrivial combination of libraries at all. The feature is about providing consistency, not ignoring it.

[v3ss0n]

My_function vs myFunction Is fine but do_me vs dome start to differ and do_me vs d_ome vs dom_e start to make things very much different.

That's the real problem

[xigoi]

Rarely a problem. Why would you have two procedures named do_me and dome with the exact same signature?

[int_19h]

Because the other procedure does something with some dome?

[xigoi]

Then is should be named doSomethingWithDome.