Camel case types

[brson]

Convert existing rust code to camel case types, variants and traits.

[mitsuhiko]

Let me add something to the discussion that crossed my mind multiple times ofter the last few years. One thing I always admired about Ruby was that as a side effect of how it implements constant lookups class names had to be CameCased. Now exceptions. This was huge for me because it made Ruby code look very consistent compared to Python.

As a side effect of Python's history some internal types (which previously were factory functions) like int and str are lowercase whereas classes and types in extension modules were usually camel cased. When the language grew many more people joined and did not know why some types were lowercase and others were not, and now we have an ungodly mix of name styles for classes. You will find collections.defaultdict but collections.OrderedDict, datetime.datetime but unittest.TestCase.

The sadness does not stop there. Even within the standard library you will see both TestCase.assertEqual as well as JSONDecoder.raw_decode. Worse than that, when code was merged around you end up with two different name styles on the same thing. The IO classes now have readline (all lowercase), _checkReadable (camelcase) and _abc_registry (lowercase and underscores).

That problem is not unique to Python. C++ started with lowercase_and_underscore for types and methods on types which also continues to classes that show up as common patterns (such as iterators). Obviously company internal classes have to respond to that, but then you will see unmatching method names on the same object. You will see Foo::reverse_iterator and then the same class has a Foo::getInstance. Or a typedef std::map<FooType, BarType> VerySadMap.

Since Rust already started questioning a few things I propose thinking about enforcing identifier naming for non export types. CamelCase for types lowercase_and_underscores for methods, functions and variables. UPPERCASE_WITH_UNDERSCORES for constants.

For externed things this should not apply to make it still easy to call into things like glCompileShader without having to alias them.

I understand that this is a super controversial thing to do, but since Rust is all about exploring things and at the same time being a very usable language I wanted to bring it up.

Note that I do not want anyone to enforce a specific style to indent or place whitespace. That's something internal to your codebase. However the names are exported through crates or ABIs and as such are something more programmers than just the original author are concerned with. Especially when it comes to inheriting or traits this is shared space.

At the end of the day I don't think forcing people to adhere to rules there is a too crazy thing to do. You can have discussions about fooBar over foo_bar or the other way round all day long and you can see arguments from both sides and usually a decision is made within a company or organization. If the language does the decision for you there is no arguing. I feel like the discussion could be viewed in the same way as driving on the left or right side. Once a decision is made there is less chaos on the street :-)

[brson]

I'm in favor of enforcing naming conventions as well. There is already a lint check for camel case (turned off by default currently since most code isn't using camel case) and I think there should be checks for both the rules you mentioned, as well as others that are agreed upon in the future. I would be ok with turning them on be default.

I do think lint is the right place to put these checks so that they can be switched on and off as needed - making the conventions strictly required is too strict for my tastes.

[brson]

See also #3070

[bblum]

@mitsuhiko all very well said. I like this proposal.

(i wonder if i would like the proposal less if i didn't also happen to agree with the specific style guidelines proposed...)

[alex]

@bblum you almost certainly would, I've worked in languages that enforced styles I don't like and it's something of a hell. That said this is my preferred style as well. However, something to me feels fundamentally wrong about specifying this type of information implicitly with a style guide, on the other hand when the alternative is more syntax clutter this idea seems much more palatable.

[brson]

Both core and std are converted. Other code will just have to be converted in passing.