I decided to do the following about this issue:
  • Nimrod will become case sensitive and enforce a naming scheme!
  • Nimrod will support a classic mode that's much more permissive for the guys of us who know petty consistency is a poor man's approach to correctness.
  • After 0.9.4 is released most types with T/P prefixes will be deprecated and replaced by versions without them.

We will provide a tool to make all your Nimrod code consistent. In fact this tool already exists: nimrod pretty project converts all of your project to a consistent style. For now this tool achieves a conversion rate of perhaps 95% of your code; in particular importc'ed symbols that rely on the way the Nimrod symbol is spelt are not touched. We can make it 100% but that's quite some effort and I don't think it's justified: We are not version 1 and people in general seem to be quite forgiving and willing to update their code.

The naming scheme will be like this:

  1. A variable is spelt in camelCase. So is a let variable and a parameter.
  2. Any field of an object or tuple is in camelCase.
  3. Any kind of routine (proc/iterator/template etc.) is in camelCase.
  4. Types are in PascalCase. This includes Int, Bool etc!
  5. Since consts are both nullary functions and quite like let-variables they are either camelCase or PascalCase. Note that ALL_CAPS constants are not allowed. The ALL_CAPS convention stems from C's preprocessor. Since we don't have a preprocessor it is unnecessary. Personally I read ALL_CAPS as shouting and consider it archaic. Constants are good style and everywhere in Nimrod so it doesn't make sense to make them stand out. If anything mutable global variables should stand out like that.
  6. Enum fields are constants.
  7. Underscores are not part of any name. Otherwise the naming convention becomes "camel case with underscores". Which is equivalent to any identifier that compiles.
  8. Write Tcp instead of TCP as camelCase doesn't work with well with abbreviations.

Note how the naming scheme really only makes the casing of the first character significant. We exploit this fact for Nimrod's classic mode which is style insensitive like Nimrod is now except that the casing of the first character is case sensitive. This way there are no interoperability issues whatsoever between modules in different modes.

Note that the classic mode only exists for lonesome coders who don't plan to publish their code. I feel bad for enforcing a style onto these people.

If you don't like this plan, please speak up now!

2013-08-01 08:14:21
Better sooner than later, although it's painful to convert bindings. What about enums? Whill the prefixes be used or only EnumType.enumConst will be allowed? 2013-08-01 08:40:44
That will be decided on a case by case basis: For instance I really prefer tagB over HtmlTag.B as the latter assumes these constants aren't used excessively. 2013-08-01 08:51:09

And how will T/P types be called then, e.g.

type
   MyStruct = object ...
   PMyStruct = ... ?

2013-08-01 08:51:36
The common type gets the name without the prefix: Socket, File, Rope; the uncommon variant gets the T/P prefix. Or maybe a Ref, Ptr, Obj suffix instead. 2013-08-01 08:56:59

> 5. Since consts are both nullary functions and quite like let-variables they are either camelCase or PascalCase.

I think it would be better to only allow PascalCase for types. That way we can guarantee that anything which starts with an uppercase letter is a type.

> 8. Write Tcp instead of TCP as camelCase doesn't work with well with abbreviations.

I'm not too sure about this, I am accustomed to writing the acronym in all caps but I can appreciate that it looks odd with camelCase: TCPServer vs. TcpServer. HTTPServer vs. HttpServer. I guess it's fine. Some people may not be so open-minded however.

> The common type gets the name without the prefix: Socket, File, Rope; the uncommon variant gets the T/P prefix. Or maybe a Ref```, ``Ptr, Obj suffix instead.

I quite like this. However I worry that some people may complain that it's not 'consistent', but oh well.

2013-08-01 11:26:38

> 5. Since consts are both nullary functions and quite like let-variables they are either camelCase or PascalCase.

Hu? This doesn't make sense. Both functions and variables are in camelCase. I planned to allow PascalCase for some OpenGL constants which otherwise clash with proc names. Oh well. However, PascalCase has the advantage that people can write them as ALL_CAPS then in classic mode.

2013-08-01 11:37:05

I try to avoid discussions about style, but since you asked for us to speak up: I don't like it.

I prefer snake_case, so the enforced rule invalidates 100% of my source code. But that's not important, with the tool and some tweaking new versions can be made. I'm already enforced to use camelCase in every other language I know, so I don't care about that either, real life sucks anyway.

I don't like the concentration of effort and discussion on such an irrelevant feature of a language, leaving more important features languish. I learned about Nimrod because I was searching the internet for a specific set of features, and Nimrod had them all. Nowhere in my search was style a bullet point. In fact, most code examples I looked at were camel case, so the case insensitivity wasn't even on my radar when I started using it. I might have read on it, but until you start writing code yourself and experience it it's as irrelevant as a breeze of air.

My conclusion is that this change is sad because it is the perfect example of how much bikeshedding can delay, or even fuck up good projects. I only hope the effort pays off in marketing and you attract all the world's programmers you are targeting with the change.

Good luck.

2013-08-01 11:47:32
i feel bad for bindings to c/c++ libs though, escpecially aforementioned OpenGL... and some libs use all_low_case_with_dash names. 2013-08-01 11:51:27

> > 5. Since consts are both nullary functions and quite like let-variables they are either camelCase or PascalCase.

> Hu? This doesn't make sense. Both functions and variables are in camelCase. I planned to allow PascalCase for some OpenGL constants which otherwise clash with proc names. Oh well. However, PascalCase has the advantage that people can write them as ALL_CAPS then in classic mode.

I would really love if PascalCase was exclusive to types. That is how it works in Haskell and I think it's great. Allowing it for constants just for some wrappers doesn't seem worth it when we have the opportunity to adopt such a nice convention.

2013-08-01 12:32:23
<<<••123456••>>>