camelCase vs snake_case

[morgon]

Hi,

more a question about Perl-programmers rather then Perl itself, but I wonder:

When discussing camelCase vs snake_case as coding-convention for a project - do you have a personal preference and if so how would you defend it apart from "that's my taste" or "Damian does it like that"?

[Athanasius]

Here is a summary of the advice offered by the Camel Book (4th Edition, p. 704) on the naming of identifiers in Perl:

Identifier	Variable	Subroutine
Constant	$ALL_CAPS_HERE
Non-lexical filehandle	FILE
Package-wide global	$Some_Caps_Here
Package name	CamelCase
Lexicals and subs	$no_caps_here	process_data
Private to a package	$_leading_underscore	_frobnicate

I do not advocate this style merely because it happens to be the one recommended in the language’s definitive reference. (I personally dislike the K&R style it recommends for brace placement, pp. 701–2.) But in this case I think the advice is useful, because the different naming conventions aid the reader in distinguishing the different ways in which identifiers are used in code.

As sundialsvc4 and Tux have said, consistency is the key. In a coding environment where programmers are likely to ignore style guidelines, a single one-case-fits-all style may be preferable (because easier to enforce). But in the general case, the visual distinctions provided by the various naming styles listed above aid comprehension and are worth learning, IMO.

[moritz]

Most CPAN modules use CamelCase for package names (in fact lower case package names are, by convention, reserved for pragmas), and use snake_case for routines.

I stick to the same convention, because consistentcy is a good thing.

[Your Mother]

     ThereAreNoRulesSoDoWhatYouLike
     there_are_no_rules_so_do_what_you_like

If my preference isn't obvious, you can consider other impossible to satisfy stylistic situations in things like XMLLib v XmlLib. I do think keeping to an expected style is good practice. E.g., the camel casing in XML::LibXML isn't annoying because it reflects the native/standard names.

[Tux]

I am with sundialsvc4 on this. BE CONSISTENT (and thus predictable).

One small addition. If a complete projects talks to another project, and that other project already follows rules for naming conventions, it might be wise to follow those rules, as it is highly expectable that developers of either will have to dig in the code of the other. Having the same variable and method names helps a lot.

Just my ¢2

[BrowserUk]

See "Justifictions" for my take on it.

[FunkyMonk]

One is readable and the other is CaMelCaSe :-)

[greengaroo]

Funny enough, I changed ways of doing things several times during my career. I remember that I use to make most of my variables CamelCase in the beginning. After reading stuff and meeting other developers and seeing other people's code, I gradually changed.

So now, for variables, I don't use uppercase because Perl itself uses it for internal variables, such as @ARGV or %ENV. You never know, maybe you can stumble on a pre-defined variable by mistake! So CamelCase or snake_case? Well I choose snake_case because in my experience, I often had errors from mistyping one of the letters, for example: $staticAlert instead of $StaticAlert. I think snake_case is easier to read too. I use the same rule for methods or subroutine names.

For modules, I use CamelCase. I don't like modules in lowercase or snake_case because when you have something like this: My::NameSpace::something_to_do, how can you know at first glance if something_to_do is another module or a subroutine of NameSpace? So I stick to CamelCase for modules and that works well for me.

[sundialsvc4]

Beyond utter and complete consistency, “no.”

[talexb]

My preference when it comes to writing code is readability. What that really means is readability to me. Everyone has a different ideal on how to make code readable.

To me, a variable name like $camelCase is very readable. The sigil is full height, and that's followed by a lower case letter. After that, each word within the variable name starts with a capital letter. It's also easy to type: just upper and lower case letters. That's the typography angle for you.

A variable name like $camel_case is not as friendly from a typing point of view -- I have to stop typing letters and go and hit the underbar. This gets worse if it's $a_really_long_variable_name; I never learned to type properly, so my typing style probably contributes to this.

Worse than this is the choice that combines camelCase with snake_case .. $a_Very_Long_Variable_Name. If you're able to type that easily and quickly, good for you -- I'll never use it.

Finally, I've met Damian a few times when he's visited Toronto -- he's a very entertaining speaker and is extremely knowledgeable about Perl and Computer Science. Still, I don't agree with *everything* he says -- in some cases I have my own preferences.

[johngg]

My personal preference is camelCase as I find it easier to read and easier to type. I also find that snake_case is more prone to error (I actually typed snake-case before spotting my mistake) and makes for even longer lines if you use long, descriptive variable names. The only problem using camelCase is if your variable name contains an upper-cased acronym in which situation things can get ugly :-(

[BrowserUk]

The only problem using camelCase is if your variable name contains an upper-cased acronym in which situation things can get ugly

FWIW: I usually find that in that case, start the word after the acronym with a lower case letter -- as with the first word, and things clarify.

Eg. my $countOfFSBblocks;

[Anonymous Monk]

I'm flexible :)

I usually use one word lowercase, or 1.3 word lowerca se, or two word camelCase

I use snake_case when I'm trying to $get_somebody_to_read_stuff $or_pause

[KevinZwack]

Personally I prefer camelCase; less typing and easier to read

Wikipedia has a some good material on camelCase etc. for those that might be interested.