4 ms·

Related, and very much a personal preference: Given that there will be no classes etc, isn't the use of camel case (and the not-that-different Pascal Case) for

Related, and very much a personal preference: Given that there will be no classes etc, isn't the use of camel case (and the not-that-different Pascal Case) for both structs and functions giving up a dimension of distinction? The ClassCamel and snake_function_case split of Python and Rust is something I bikeshed about often - sooner or later 'IO', 'TCP' or 'MMbT' needs to be CamelCased and then it all goes downhill. Or C and C++ (the latter is also mentioned as an inspiration), which never used CamelCase. I think Java then used it purely to distinguish itself also by style from these direct and unsafe memory poking languages.

nickmqb 8y ago
I'm not sure if I understood your question correctly, but lowerCamel vs snake_case is not guaranteed to be different right? E.g. if you have an identifier consisting of a single word. I'd recommend using UpperCamel for namespaces/types (including structs), and either lowerCamel or snake_case for everything else. I personally like that approach because it makes it possible to distinguish between a regular function call and an instance call, e.g.: SomeNamespace.foo() vs someLocalVar.bar(). That said, the language doesn't enforce any particular naming scheme, so people are free to do what they want. Once the type aliasing feature lands, they can even create alternate names for existing types.
cpeterso 8y ago
I'm surprised that Ada's Camel_Snake_Case isn't more common. It's no more verbose than snake_case but easier to read the words like a natural language and avoids acronym capitalization ambiguities, e.g. "XML_HTTP_Request" instead of "XMLHttpRequest".
- int_19h 8y ago
  I think it's uncommon because it is redundant - if you already have underscores to separate words, why capitalize? Personally, though, I find casing to be a better way to split up words in languages which have . as a member access operator, for the simple reason that it makes property or method call chains more readable. When you have both dots and underscores in the mix, they both register up as whitespace first, and then you have to distinguish which is which. When it's just dots, it's clear where the boundaries are.

nickmqb 8y ago

I'm not sure if I understood your question correctly, but lowerCamel vs snake_case is not guaranteed to be different right? E.g. if you have an identifier consisting of a single word. I'd recommend using UpperCamel for namespaces/types (including structs), and either lowerCamel or snake_case for everything else. I personally like that approach because it makes it possible to distinguish between a regular function call and an instance call, e.g.: SomeNamespace.foo() vs someLocalVar.bar(). That said, the language doesn't enforce any particular naming scheme, so people are free to do what they want. Once the type aliasing feature lands, they can even create alternate names for existing types.

cpeterso 8y ago

I'm surprised that Ada's Camel_Snake_Case isn't more common. It's no more verbose than snake_case but easier to read the words like a natural language and avoids acronym capitalization ambiguities, e.g. "XML_HTTP_Request" instead of "XMLHttpRequest".

int_19h 8y ago
I think it's uncommon because it is redundant - if you already have underscores to separate words, why capitalize? Personally, though, I find casing to be a better way to split up words in languages which have . as a member access operator, for the simple reason that it makes property or method call chains more readable. When you have both dots and underscores in the mix, they both register up as whitespace first, and then you have to distinguish which is which. When it's just dots, it's clear where the boundaries are.