Professional Web Applications Themes

Appropriate use of camelCase - Ruby

Following the 'instance variable capitalization' thread, I'm convinced that I should be trying to learn the Ruby idioms. Now I just need to learn what they are. While writing my ValidForm library (http://phrogz.net/RubyLibs/) I realized that I was mixing camelCase [which I love] with whatever_you_call_this_case [which I don't, but I see that Ruby uses a lot of]. (BTW...what *do* you call that naming style? snake_case? That's what I'll call it until someone corrects me.) I tried starting to eradicate camelCase, but found that I just couldn't do it completely[1], and came up with the following idiom for that particular library[2]: ...

  1. #1

    Default Appropriate use of camelCase

    Following the 'instance variable capitalization' thread, I'm convinced
    that I should be trying to learn the Ruby idioms. Now I just need to
    learn what they are.

    While writing my ValidForm library (http://phrogz.net/RubyLibs/) I
    realized that I was mixing camelCase [which I love] with
    whatever_you_call_this_case [which I don't, but I see that Ruby uses a
    lot of]. (BTW...what *do* you call that naming style? snake_case? That's
    what I'll call it until someone corrects me.)

    I tried starting to eradicate camelCase, but found that I just couldn't
    do it completely[1], and came up with the following idiom for that
    particular library[2]:

    * 'Verb' methods (named like they do something, and generally called
    with parameters, or where the action they produce is more important than
    their return value) I named using snake_case.

    * 'Noun' methods (aka 'property' methods...methods which behave like
    getters and setters of an internal instance variable [whether or not
    they actually do] which are called explicitly to get a return value or
    with a foo= assignment method to set a value) I named using camelCase.



    I was very proud of my semi-rational rationale, in finding a way that I
    felt was both Ruby-esque, which actually sort of conveyed additional
    information with the camelCase vs. snake_case usage. But I realize it's
    an idiom I made up completely on my own.


    So, to the Question: is the above just a Bad Idea? Is camelCase *ever*
    considered appropriate in Ruby?

    - Gavin


    [1] The problem for me (and this is not to start a flame war, just a
    personal exposition) is that camelCase is just so much easier to type,
    and (to me) LOOKS like a property.

    [2] Whether or not I succeeded in religiously adhering to my proposed
    idiom I'm not sure...I got disheartened after a while of global
    find/replaces, upon how many pretty camelCases were disappearing.

    --
    (-, /\ \/ / /\/
    Gavin Guest

  2. #2

    Default Re: Appropriate use of camelCase

    Hi,

    In message "Appropriate use of camelCase"
    on 04/02/23, Gavin Kistner <com> writes:

    |So, to the Question: is the above just a Bad Idea? Is camelCase *ever*
    |considered appropriate in Ruby?

    We don't force you. You are completely free. But I prefer under_score
    names, and never use CamelCase except for class/module names in Ruby.

    matz.


    Yukihiro Guest

  3. #3

    Default Re: Appropriate use of camelCase

    Gavin Kistner wrote: 

    For what it's worth, this is the opposite of how I do it, and here's why:

    * If it looks and acts like a variable, I name it like a variable, for
    which I use 'snake_case'.

    * If it is a verb method that does something, that's where camelCase
    makes sense to me.

    I think it's important to visually distinguish the different types of
    things in a program. To do this, I use ALL_CAPS_WITH_UNDERSCORES for
    constants, all_lowercase_with_underscores for variables, and
    variable-like attribute accessors. I use CamelCaseWithLeadingCap for
    class like things, and finally I useCamelCaseWithLeadingLowercase for
    methods that do something.

    That makes it easy to glance at a 'word' and see what it is and what it
    does.

    On top of that, I'm careful in how I name things. Constants, variables
    and classes are nouns, methods are active verbs. The reason I think
    camelCase is useful to distinguish methods from variables/accessors is
    when it comes to things named 'read_number'. Is that a variable that
    stores the number of times something was read? Is it a method that
    instructs something to read a number? The only way I know of to make
    that unambiguous is camelCase. readNumber is the method, read_number is
    the variable. Voila.

    Maybe that's just me tho.

    Ben


    Ben Guest

  4. #4

    Default Re: Appropriate use of camelCase

    Hi,

    At Tue, 24 Feb 2004 09:51:19 +0900,
    David A. Black wrote in [ruby-talk:93516]: 

    They all aren't method names; regexps, string literals, local
    variables, or comments.

    --
    Nobu Nakada


    nobu.nokada@softhome.net Guest

  5. #5

    Default Re: Appropriate use of camelCase

    Chunky bacon!
     
     
    >
    > You can get at least a good rough idea from the source. From
    > /usr/local/lib/ruby/1.8:
    >
    > $ ruby -ne 'print if /\b[a-z]+[A-Z]/.match($_)' `find -name "*.rb"` | wc -l
    > 862
    > $ ruby -ne 'print if /\b[a-z]+_[a-z]/.match($_)' `find -name "*.rb"` | wc -l
    > 19943[/ref]

    Hmm.

    0$ egrep -r 'def +[a-z]+[A-Z]' lib
    lib/cgi.rb: def nOE_element_def(element, append = nil)
    lib/cgi.rb: def nO_element_def(element)
    lib/parg.rb:def printUsageAndExit()
    lib/parg.rb:def setParenthesis(ex, opt, c)
    lib/parg.rb:def setOrAnd(ex, opt, c)
    lib/parg.rb:def setExpression(ex, opt, op)
    lib/parg.rb:def pArgs(argc, nopt, single_opts, *opts)
    lib/xmlrpc/create.rb: def methodCall(name, *params)
    lib/xmlrpc/create.rb: def methodResponse(is_ret, *params)
    lib/xmlrpc/httpserver.rb: def writeTo(port)
    lib/xmlrpc/pr.rb: def removeChild(node)
    lib/xmlrpc/pr.rb: def childNodes
    lib/xmlrpc/pr.rb: def hasChildNodes
    lib/xmlrpc/pr.rb: def nodeType
    lib/xmlrpc/pr.rb: def nodeValue
    lib/xmlrpc/pr.rb: def nodeName
    lib/xmlrpc/pr.rb: def pMethodResponse(str)
    lib/xmlrpc/pr.rb: def pMethodCall(str)
    lib/xmlrpc/pr.rb: def removeWhitespacesAndComments(node)
    lib/xmlrpc/pr.rb: def nodeMustBe(node, name)
    lib/xmlrpc/pr.rb: def hasOnlyOneChild(node, name=nil)
    lib/xmlrpc/pr.rb: def dateTime(node)
    lib/xmlrpc/pr.rb: def methodResponse(node)
    lib/xmlrpc/pr.rb: def methodName(node)
    lib/xmlrpc/pr.rb: def methodCall(node)
    lib/xmlrpc/pr.rb: def pMethodResponse(str)
    lib/xmlrpc/pr.rb: def pMethodCall(str)
    lib/xmlrpc/pr.rb: def startElement(name, attrs=[])
    lib/xmlrpc/pr.rb: def endElement(name)
    lib/xmlrpc/pr.rb: def methodResponse_doent(node)
    lib/xmlrpc/pr.rb: def methodCall_doent(node)
    lib/xmlrpc/pr.rb: def createCleanedTree(str)
    lib/xmlrpc/pr.rb: def methodResponse_doent(node)
    lib/xmlrpc/pr.rb: def methodCall_doent(node)
    lib/xmlrpc/pr.rb: def createCleanedTree(str)
    lib/rss/xmlpr.rb: def startElement(name, attrs)
    lib/rss/xmlpr.rb: def endElement(name)
    lib/rss/xmlpr.rb: def xmlDecl(version, encoding, standalone)
    lib/rdoc/markup/simple_markup/lines.rb: def isBlank?
    0$

    (Only checked method name)

    Back to the topic, here is the coding convention for library
    which is bundled with ruby. [ruby-talk:62890], [ruby-talk:62894].

    * use two-space indentation, no TABs
    * use RDoc
    * shouldn't use camelCase for variable names and method names
    * use camelCase for class names and module names
    * use upper case separated by '_' for constants

    Library users never want to mix under_scoer and camelCase. So,

    1. Overturn the matz and rubyists's way, then rewrite all libs, or
    2. Please use under_score name for users.

    Regards,
    // NaHi


    NAKAMURA, Guest

  6. #6

    Default Re: Appropriate use of camelCase

    Kirk Haines wrote:
     
    > .
    > .
    > .
    >

    >
    >I don't see this as that much of a factor, personally. It really boils
    >down to aestetics. The ripe_with_underscores_everywhere style is
    >pervasive in the Perl world, as well, but there are quite a few people who
    >program in Perl who use CamelCase either because that's just what they are
    >used to, or because they think that CamelCase, at least in certain
    >instances, looks better or is easier to read.
    >
    >I personally have less discipline on this subject than I probably should
    >have, but generally I use CamelCase for verbs and underscore_case for
    >nouns. It's easier for me to read a page of code if there is something
    >like CamelCase jumping out at me when methods are being invoked. It's
    >personal preference and making the choice that is most efficient for my
    >uses. I imagine the same can be said for people like yourself who abhor
    >CamelCase. I imagine that if you were writing Java code, your inclination
    >would be to use underscore_case (or snake_case; I kind of like that term),
    >because that is what feels better on your brain, yes?
    >
    >
    >Kirk Haines
    >
    >
    >
    >
    >[/ref]
    camel_case
    camelCase

    mas or menos

    9 is less than 10 is about the only good argument that is not subjective
    that i can see

    ...well except for the fact that ruby/matz likes 'snake_case'

    10 is less than 9!

    :P


    Paul Guest

  7. #7

    Default Re: Appropriate use of camelCase

    Kirk Haines wrote:
     
    FWIW, I have yet to hear a good reason for hard tabs. :) As soon as a
    *single* space is used *anywhere* on a line after tabs, the tabs mean
    nothing and will cause the indentation to be mismatched on someone
    else's system. With spaces, the indentation is *always* correct.




    Patrick Guest

  8. #8

    Default Re: Appropriate use of camelCase

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On Monday 23 February 2004 10:32 pm, Patrick Bennett wrote: 

    Don't go there. :-)

    - --
    Jason Voegele
    I like tabs.
    http://derkarl.org/why_to_tabs.html

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.3 (GNU/Linux)

    iD8DBQFAOtHeZzKiUg/stvoRAoelAJ9tzB3EmMu4tdtiRPC5zUNJnVkf6QCgthC1
    P4YpoQRDxpsK15tmY/im6rQ=
    =IyDS
    -----END PGP SIGNATURE-----




    Jason Guest

  9. #9

    Default Re: Appropriate use of camelCase (Tabbing in emacs)

    On Tuesday, 24 February 2004 at 12:32:46 +0900, Patrick Bennett wrote: 
    > FWIW, I have yet to hear a good reason for hard tabs. :) As soon as a
    > *single* space is used *anywhere* on a line after tabs, the tabs mean
    > nothing and will cause the indentation to be mismatched on someone
    > else's system. With spaces, the indentation is *always* correct.[/ref]

    Speaking of tabs, I have a colleague that uses emacs. Using
    ruby-mode.el, <tabbing> indents two spaces, unless he tabs
    4 times. Then the 8 spaces are converted to a hard tab.

    Is there a way to prevent this from happening? Particularly, is
    there a way for ruby-mode.el to do this so he does not have to
    permanently change his tab setting in emacs.

    Thanks

    --
    "I went to a job interview the other day, the guy asked me if I had any
    questions , I said yes, just one, if you're in a car traveling at the
    speed of light and you turn your headlights on, does anything happen?

    He said he couldn't answer that, I told him sorry, but I couldn't work
    for him then.
    -- Steven Wright


    Jim Guest

  10. #10

    Default Re: Appropriate use of camelCase (Tabbing in emacs)

    In Message-Id: <org>
    Jim Freeze <org> writes:
     

    Add the following to your colleague's .emacs:

    (add-hook 'ruby-mode-hook
    #'(lambda () (setq indent-tabs-mode nil)))

    Or just

    (setq-default indent-tabs-mode nil)

    for any language modes.


    --
    to February 24, 2004
    Every body's business is nobody's business.



    YANAGAWA Guest

  11. #11

    Default Re: Appropriate use of camelCase (Tabbing in emacs)


    "Jim Freeze" <org> schrieb im Newsbeitrag
    news:org... 
    > > FWIW, I have yet to hear a good reason for hard tabs. :) As soon as[/ref][/ref]

    >
    > Speaking of tabs, I have a colleague that uses emacs. Using
    > ruby-mode.el, <tabbing> indents two spaces, unless he tabs
    > 4 times. Then the 8 spaces are converted to a hard tab.
    >
    > Is there a way to prevent this from happening? Particularly, is
    > there a way for ruby-mode.el to do this so he does not have to
    > permanently change his tab setting in emacs.[/ref]

    I'm not an emacs expert and the only solution that I would come up with is
    to write a hook that sets indent-tabs-mode to nil when entering ruby mode.

    Regards

    robert

     

    Robert Guest

  12. #12

    Default Re: Appropriate use of camelCase (Tabbing in emacs)

    Hi,

    At Tue, 24 Feb 2004 21:40:22 +0900,
    YANAGAWA Kazuhisa wrote in [ruby-talk:93555]: 
    >
    > Add the following to your colleague's .emacs:
    >
    > (add-hook 'ruby-mode-hook
    > #'(lambda () (setq indent-tabs-mode nil)))[/ref]

    Since 2003/02/17, ruby-indent-tabs-mode is used for that
    purpose, and defaulted to nil.

    --
    Nobu Nakada


    nobu.nokada@softhome.net Guest

  13. #13

    Default Re: Appropriate use of camelCase (Tabbing in emacs)

    On Tuesday, 24 February 2004 at 21:40:22 +0900, YANAGAWA Kazuhisa wrote: 

    Thanks


    --
    Jim Freeze


    Jim Guest

  14. #14

    Default Re: Appropriate use of camelCase

    On Feb 23, 2004, at 7:11 PM, Kirk Haines wrote: 

    I agree that what matters is consistency, and what_works_for_you. (See,
    I'm getting the hang of it already! :)

    I didn't mean (too much) to start a religious debate. The thing is, I'm
    a blank slate when it comes to Ruby. Sure, I have a bit of baggage from
    past languages, but I'm starting fresh and I want to be clean.

    Further, consistency is important not just within my own code, but
    within the community if I plan on ever contributing back. So I want to
    learn to be consistent with whatever prevalent pseudo-standard may
    exist.

    Although the topic *is* ripe for a holy war, and some (including
    myself) certainly prefer camelCase in some instances, it appears that
    the vast majority use snake_case for everything but
    ClassAndModuleNames. (Which really, I never thought was in any doubt; I
    can't imagine a class name with an underscore.)

    So...as proud as I was of my nouns/verbs rationale for including
    camelCase in method names, I will henceforth use snake_case only for
    method names, UpperCamelCase for class/module names, and
    SHOUTING_AT_THE_TOP_OF_MY_LUNGS case for constants.


    Despite the touchy subject, thank you all for your feedback.

    (And don't even get me started on the tabs issue! :p)
    --
    (-, /\ \/ / /\/



    Gavin Guest

  15. #15

    Default Re: Appropriate use of camelCase

    Gavin Kistner <com> writes:
     

    True. However, the standard only matters at the interface level.
    As long as you use snake_case for your methods and PUBLIC_CONSTANTS,
    you're free to use camelCase for private local variables if you like. :)

    -Mark
    Mark Guest

  16. #16

    Default Re: Appropriate use of camelCase

    Kirk Haines wrote: 

    In emacs ruby-mode, hitting 'tab' means to indent the code by the
    appropriate amount. For me, it always does this using spaces.
     

    Again, with emacs, if you want to change your indentation level, just
    change your 'basic-offset' setting, select the whole buffer and run
    'indent-region', it will reformat the entire buffer (or just the
    selected part) according to your new setting.

    As others have said, the problem isn't with tabs or spaces, it's with
    tabs *AND* spaces. If you mix them, you cause problems. The trouble
    is, it's really easy to mix them. Take the following code snippet:

    print("This is the start of a very long string that " +
    "I'm continuing on the next line.")

    Most people that I know would want it lined up as above, so that the
    start of the second string lines up with the start of the first one,
    however that's six characters in. What happens when both lines are
    indented, as in:

    if (print_string)
    print("This is the start of a very long string that " +
    "I'm continuing on the next line.")
    end

    If you're using tabs to indent, the second line should contain 1 tab,
    followed by 6 spaces. But what if your editor thinks that a tab is 4
    spaces? I would bet that under most cirstances it would insert 2
    tabs and 2 spaces.

    Anyhow, some good reading on this issue, with some vi/emacs methods of
    dealing with it can be found on Jamie Zawinski's site:

    http://www.jwz.org/doc/tabs-vs-spaces.html

    Ben


    Ben Guest

  17. #17

    Default Re: Appropriate use of camelCase

    On Wednesday, February 25, 2004, 1:11:16 AM, Kirk wrote:
     
     [/ref]
     


    I use Vim, and almost never have to touch the TAB or SPACE key for
    indentation purposes. Vim just puts the cursor where it should be
    after I hit ENTER. Moving a set of lines in or out one indent level
    is very easy (:help >), and re-auto-indenting a bunch of code is too
    (:help =).

    So speed is, thankfully, never an issue.

    Cheers,
    Gavin



    Gavin Guest

  18. #18

    Default Re: Appropriate use of camelCase

    Kirk Haines wrote:
     
    >
    >And I agree with you here. If I were writing code that was going to be in
    >the standard library, I'd go through the pain of conforming my style to
    >the described "Ruby" style so that it fits in with the rest of the code.
    >
    >When writing the code that keeps my family fed, though, it is far too hard
    >to make sure my Perl adhere's the the described Perl community's style,
    >and my Java to the described Java community's style, and my Ruby to Ruby
    >style, and my Bash scripts to yet a different style, and my C to....
    >It's too many completely arbitrary styles. Far better for me to use the
    >style that fits best with the way I work and the way that I read code and
    >to do so consistently across everything that I have to produce and to
    >maintain.
    >[/ref]
    That seems like a real world use of case to me. Some of the
    comments here tend to be a bit zealot'ish. I find your approach not only acceptable but preferred. Not that you are, but I would not sweat it too much.

     




    Paul Guest

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139