[dilap]

Thanks, that's interesting. I see the justification for it, at least.

I don't know if the whole world is magically living with much more orderly developers than I have had the pleasure to work with, but I guarantee you that if I were using such a project at work, we'd end up with the same variable being referenced different ways.

I really wouldn't be able to grep for variables with confidence.

(Cf. Carmack: Everything that compiles will ultimately end up in your code. In the context of exploring static analysis tools, which were finding lots of errors.)

I do like the idea for uniformity though, but it seems like maybe better to restrict it -- define project-based 'style-rules', and automatically translate when moving between domains.

So foo_bar inside package A must be accessed as FooBar inside package B.

[jitl]

These style issues are trivial to enforce at commit time (pre-commit hook) and build time with a linter. It’s easy to enforce the order you desire upon your developers.

[dilap]

does such a linter actually exist, or is this the mathematicians trivial, "it is not required to discover something new to do it"?

[arc776]

> I guarantee you that if I were using such a project at work, we'd end up with the same variable being referenced different ways.

Luckily this is trivial to resolve as the compiler reports ambiguous variables as errors and you can then prefix by module name if required.

[dilap]

Hmm, maybe I misunderstood the feature.

If I have a variable declared as fooBar, and somewhere else in the code someone refers to it as fooBAr, does that compile, or is it an error?

[dom96]

It compiles, but is definitely considered bad style.