Beefy Boxes and Bandwidth Generously Provided by pair Networks Bob
P is for Practical
 
PerlMonks  

camelCase vs snake_case

by morgon (Chaplain)
on Aug 28, 2012 at 23:17 UTC ( #990350=perlquestion: print w/ replies, xml ) Need Help??
morgon has asked for the wisdom of the Perl Monks concerning the following question:

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"?

Comment on camelCase vs snake_case
Re: camelCase vs snake_case
by Your Mother (Canon) on Aug 28, 2012 at 23:32 UTC
    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.

Re: camelCase vs snake_case
by FunkyMonk (Canon) on Aug 28, 2012 at 23:49 UTC
Re: camelCase vs snake_case
by BrowserUk (Pope) on Aug 29, 2012 at 00:15 UTC

    See "Justifictions" for my take on it.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

    RIP Neil Armstrong

Re: camelCase vs snake_case
by sundialsvc4 (Monsignor) on Aug 29, 2012 at 00:17 UTC

    Beyond utter and complete consistency, “no.”

Re: camelCase vs snake_case
by Tux (Monsignor) on Aug 29, 2012 at 06:15 UTC

    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


    Enjoy, Have FUN! H.Merijn
Re: camelCase vs snake_case
by Anonymous Monk on Aug 29, 2012 at 06:55 UTC

    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

Re: camelCase vs snake_case
by Athanasius (Prior) on Aug 29, 2012 at 07:20 UTC

    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.

    Athanasius <°(((><contra mundum

Re: camelCase vs snake_case
by moritz (Cardinal) on Aug 29, 2012 at 07:27 UTC

    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.

Re: camelCase vs snake_case
by talexb (Canon) on Aug 29, 2012 at 18:35 UTC

    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.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re: camelCase vs snake_case
by greengaroo (Hermit) on Aug 29, 2012 at 18:36 UTC

    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.

    There are no stupid questions, but there are a lot of inquisitive idiots.
Re: camelCase vs snake_case
by johngg (Abbot) on Aug 29, 2012 at 22:23 UTC

    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 :-(

    Cheers,

    JohnGG

      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;


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
Re: camelCase vs snake_case
by KevinZwack (Chaplain) on Aug 31, 2012 at 15:07 UTC

    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://990350]
Approved by Old_Gray_Bear
Front-paged by Tanktalus
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (11)
As of 2014-04-18 21:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (472 votes), past polls