Misc. Naming: Can I place underscores instead of camel casing in modern languages?

Question

Hi!

I would like to ask some kind of permission (I hope that doesn't sound strange) from the people who have influence on the naming conventions in modern languages like F#, Scala, etc.

My problem is - I just can't read camelCased code and wish I could write underscored_names at least in my internal implementations (not in API interface). This applies to just everything - local var names, method names, params.. (Not class names I think)

It seems that now the camel-casing is preferred for example for the names of object methods, but could that be not the only way?

What would you say; Can I go with underscored names in languages like I mentioned (F#, Scala)?

Answer 1

Do whatever you like. Just be consistent.

Answer 2

Conventions are just that -- conventions. In most modern programming languages, an identifier must begin with a letter or underscore and may be continued with letters, underscores, or digits. The languages permit any sort of casing; it is convention, not the language, itself, that prefers the use of camel casing. That said, certain identifiers may be reserved or may have special meaning in certain languages. For example, in C++ identifiers that begin with a double underscore or an underscore followed by an uppercase letter are reserved. In Python, using a double-underscore for class members causes the names to be mangled.

You can do whatever you want in the language assuming that it is legal and the identifier is not reserved. However, just because something is legal does not mean that you should do it. Conventions exist for a reason, namely to make code written by one developer easy and intuitive to understand for another. Use of idiosyncratic casing will confuse other developers using your code. However, since you have stated that your public API will adhere to standard conventions, and you are only deviating internally, then I would say that there is no problem with doing that. However, you should be consistent in your internal implementations, so that the internal code is easy to understand and intuitive for all the developers working on that project.

Answer 3

I know in most of my text books variableName is used to represent variables in object oriented languages and variable_name is used to represent variables in non-object oriented languages (classical or procedural programming). English is my native language and I cannot say that I have had a problem with either convention. You just have to use the naming convention(s) that the programming community has deemed fit for your specific language and get used to it :)

Answer 4

I just opened a dozen of my F# projects ranging from 1k to 5k lines and it looks like I generally use camel case. A few of my projects use underscores but I don't see any mixing within a single project. I do notice that with F# I have a lot more single word identifiers. Which I prefer as long as I can give it a meaningful/logical name.

As much as I love meaningful identifiers, long identifiers make things hard to read. Don't make them long just because.

whichDoYouThinkIsMoreReadable?
which_do_you_think_is_more_readable?
moreReadable
more_readable
readable

Also, you may want to consider changing your font and/or color scheme if you have trouble reading camel case. Here are some of my favorites. Depending on your ClearType settings these fonts will look different in person.

Answer 5

The most important rule of coding style is to preserve the same coding style throughout, no matter what that code style is. This applies foremost to projects with many people.

If you choose to use underscore, there'll be a marked difference between your code and library code. It might not be bad, but it will be perceptible anyway.

Also, you'll forego IDE features that are predicated on the use of camel case, such as camel case expansion.

If you intend your project to be a public Scala project, I do beg you to keep to the general style guideline. Of course, being your project, you can do whatever you want.

For personal projects... let your feelings be your guide. By all means, do experiment with it -- personal projects are supposed to be fun!