CamelCase versus wide_names (Prothon)

Discussion in 'Python' started by Mark Hahn, Apr 15, 2004.

  1. Mark Hahn

    Mark Hahn Guest

    We have agreed in Prothon that unlike Python we are going to be 100%
    consistant in our var and method naming. We will not have run-together
    words like iteritems, we are going to always have seperated words like
    has_key.

    Now we are in the midst of a discussion of camelCase versus wide_names. So
    far our arguments are:

    1) CamelCase is more elegant, modern, more readable, and more efficient in
    character usage.

    2) Wide_names is cleaner, more readable, compatible with C, which is the
    standard module language for Python and Prothon. Wide_names is also the
    Python standard.

    Of course in the Python world you alread have wide_names as your standard,
    but could you for the moment pretend you were picking your standard from
    scratch (as we are doing in the Prothon world) and give your vote for which
    you'd prefer?

    Thanks in advance...
    Mark Hahn, Apr 15, 2004
    #1
    1. Advertising

  2. Mark Hahn

    Peter Hansen Guest

    Mark Hahn wrote:

    > We have agreed in Prothon that unlike Python we are going to be 100%
    > consistant in our var and method naming. We will not have run-together
    > words like iteritems, we are going to always have seperated words like
    > has_key.
    >
    > Now we are in the midst of a discussion of camelCase versus wide_names. So
    > far our arguments are:
    >
    > 1) CamelCase is more elegant, modern, more readable, and more efficient in
    > character usage.
    >
    > 2) Wide_names is cleaner, more readable, compatible with C, which is the
    > standard module language for Python and Prothon. Wide_names is also the
    > Python standard.
    >
    > Of course in the Python world you alread have wide_names as your standard,
    > but could you for the moment pretend you were picking your standard from
    > scratch (as we are doing in the Prothon world) and give your vote for which
    > you'd prefer?


    camelCase, provided acronyms (if any) are treated as words and
    capitalized appropriate. For example, updateGui() is preferred
    to updateGUI() (or update_GUI or update_gui). IBM did it right
    with the OS/2 API (at some point, finally).

    Of course, someone once said that a foolish consistency is the
    hobgoblin of little minds...

    -Peter
    Peter Hansen, Apr 15, 2004
    #2
    1. Advertising

  3. On Thu, 15 Apr 2004 08:17:08 -0700
    "Mark Hahn" <> wrote:

    > pretend you were picking your standard from
    > scratch (as we are doing in the Prothon world) and give your vote for
    > which you'd prefer?


    I've not really been following Prothon in general, but I'm happy to give my opinion on this....

    I think most people use whatever they 'grew up with' (in the programming sense...). I started programming in UnrealScript (Unreal/UnrealTournament coding) and I still use the naming schemes that they used in their code...

    camelCaseAllTheWay (unless I'm extending someone else's code and they've used wide_names)

    I also use kinda-hungarian notation, in that all of my boolean (or pseudo-boolean) variables are:

    bVariable

    (by pseudo-boolean I mean an int acting as a boolean, for example)

    When I'm reading code, this makes sense, as I read:

    if bTurnedOn:

    as

    If be turned on:

    Anyway, I think the answer that you're looking for from me is camelCaps all the way....


    --
    Hugh Macdonald
    The Moving Picture Company
    Hugh Macdonald, Apr 15, 2004
    #3
  4. Mark Hahn wrote:

    > Of course in the Python world you alread have wide_names as your
    > standard, but could you for the moment pretend you were picking
    > your standard from scratch (as we are doing in the Prothon world)
    > and give your vote for which you'd prefer?


    camelCase, hands down. Underscores are much too difficult to type,
    and in my opinion should be avoided except when you WANT a hard-to-type
    identifier (as with private variables, etc.).

    --
    --OKB (not okblacke)
    Brendan Barnwell
    "Do not follow where the path may lead. Go, instead, where there is
    no path, and leave a trail."
    --author unknown
    OKB (not okblacke), Apr 15, 2004
    #4
  5. Mark Hahn

    Kevin Altis Guest

    If you're using PEP 8 terminology then CamelCase is different than
    mixedCase. CamelCase is often used for class names and mixedCase for
    everything else.

    """
    - CapitalizedWords (or CapWords, or CamelCase -- so named because
    of the bumpy look of its letters[4]). This is also sometimes known as
    StudlyCaps.

    - mixedCase (differs from CapitalizedWords by initial lowercase
    character!)
    """

    ka

    "Mark Hahn" <> wrote in message
    news:UHxfc.9323$dZ1.3740@fed1read04...
    > We have agreed in Prothon that unlike Python we are going to be 100%
    > consistant in our var and method naming. We will not have run-together
    > words like iteritems, we are going to always have seperated words like
    > has_key.
    >
    > Now we are in the midst of a discussion of camelCase versus wide_names.

    So
    > far our arguments are:
    >
    > 1) CamelCase is more elegant, modern, more readable, and more efficient in
    > character usage.
    >
    > 2) Wide_names is cleaner, more readable, compatible with C, which is the
    > standard module language for Python and Prothon. Wide_names is also the
    > Python standard.
    >
    > Of course in the Python world you alread have wide_names as your standard,
    > but could you for the moment pretend you were picking your standard from
    > scratch (as we are doing in the Prothon world) and give your vote for

    which
    > you'd prefer?
    >
    > Thanks in advance...
    >
    >
    Kevin Altis, Apr 15, 2004
    #5
  6. [Mark]
    > could you for the moment pretend you were picking your standard from
    > scratch (as we are doing in the Prothon world) and give your vote for which
    > you'd prefer?


    My preference is for camel case, with initial caps only for class names:

    --------------------------------------------

    moduleVariable = 3

    def myFunction(formalParameter):
    localVariable = None

    class MyClass:
    def methodName(self, formalParameter):
    localVariable = None
    self.myAttribute = None

    --------------------------------------------

    I don't have any scientific backing for that - just "it looks right to me".

    That said, 99% of the standard library disagrees with me and uses wide_names
    (at least for method names) which is a pretty powerful argument for adopting
    that as your standard:

    $ egrep "( |\t)+def " *.py | wc
    3353 14222 154294
    $ egrep "( |\t)+def [a-z0-9]*[A-Z][a-z0-9]*\(" *.py | wc
    39 148 1645

    ....OK, 98.837% :cool:

    Class names are mostly standardised on CamelCase - hardly any have
    underscores:

    $ egrep "^class +[^(_]+_[^(]*\(" *.py | wc
    11 45 583

    --
    Richie Hindle
    Richie Hindle, Apr 15, 2004
    #6
  7. Mark Hahn

    Andrei Guest

    Mark Hahn wrote on Thursday 15 April 2004 17:17:

    > We have agreed in Prothon that unlike Python we are going to be 100%
    > consistant in our var and method naming. We will not have run-together
    > words like iteritems, we are going to always have seperated words like
    > has_key.


    I don't like underscores in variable names for the same reason as
    Brendan/OKB: they're hard to type and they slow me down because: a) it's
    one extra keypress compared to MixedCase (or CamelCase - depending on who
    you ask) and b) even at same word length, it takes longer for me to type
    the underscore than any alphanumeric character.

    Personally I also find MixedCase easier to read than under_scores
    (especially in code and especially when more than two words are
    concatenated, e.g. AskUserPermission vs. ask_user_permission - the first is
    immediateyl obvious as being one word, the second might fool me at first
    (quick) glance into thinking it's three words). I'm not sure if this
    universally true or just a matter of what I'm used to.

    --
    Yours,

    Andrei

    =====
    Real contact info (decode with rot13):
    . Fcnz-serr! Cyrnfr qb abg hfr va choyvp cbfgf. V ernq
    gur yvfg, fb gurer'f ab arrq gb PP.
    Andrei, Apr 15, 2004
    #7
  8. Mark Hahn

    Roy Smith Guest

    Here's my entirely non-scientific two cents on this.

    I stated out programming on teletypes and card punches which only had a
    single case, so I got used to underscores. When bumpyCase started
    showing up 10 or 15 years ago, I thought it was froofy and ugly and
    hated it. Gradually, I've come around and now find mixed upper/lower
    very natural (including the initial cap for class names) and despise
    underscores. If an old goat like me can change, I figure everybody else
    can too.

    It's entirely unclear how any of the above should influence your
    decisions on language design :)
    Roy Smith, Apr 15, 2004
    #8
  9. Mark Hahn

    Mark Hahn Guest

    "Roy Smith" <> wrote...

    > It's entirely unclear how any of the above should influence your
    > decisions on language design :)


    It may not technically be part of the language design, but aesthic issues
    like this need to be decided up front or they will be decided randomly.
    Users on the Prothon mailing list were asking me (I'm the BDFL there) to
    change from wide_names to camelCase and I wasn't letting them, because
    Python used wide_names and I have a rule about following Python unless there
    is a good reason to change.

    Then I came here and asked and to my surprise I'm finding out that 100% of
    python users want camelCase. This kind of blows away my argument against
    it. So camelCase it will be.

    Now I'll go through all the Python method and var names and convert them all
    to camelCase for Prothon. It shouldn't be a problem for users since the
    conversion is mechanical.
    Mark Hahn, Apr 15, 2004
    #9
  10. Kevin Altis wrote:
    > If you're using PEP 8 terminology then CamelCase is different
    > than mixedCase. CamelCase is often used for class names and
    > mixedCase for everything else.


    Just to add to the confusing terminology, in some circles mixed case with an
    initial lowercase letter is called camelCase, while mixed case with initial
    uppercase is called PascalCase. :)

    http://c2.com/cgi/wiki?CamelCase
    http://c2.com/cgi/wiki?PascalCase

    In any case ;-) Mark is referring to both forms, WithInitialCapital and
    withoutInitialCapital.

    The initial capital letter actually has significance in Prothon (I
    think--unless that has changed). So the question is whether to use
    NamesLikeThis and namesLikeThis, or Names_like_this and names_like_this.

    -Mike (instigator of the discussion and major fan of [Mm]ixedCaseNames,
    whatever they are called)
    Michael Geary, Apr 15, 2004
    #10
  11. On Thu, 15 Apr 2004 08:17:08 -0700,
    Mark Hahn <> wrote:
    > Of course in the Python world you alread have wide_names as your standard,
    > but could you for the moment pretend you were picking your standard from
    > scratch (as we are doing in the Prothon world) and give your vote for which
    > you'd prefer?


    Wide_names: for a while I wrote code using mixedCase, but subsequently
    switched back; the resulting method/function names are easier to read
    and to talk about.

    --amk
    A.M. Kuchling, Apr 15, 2004
    #11
  12. Mark Hahn

    JCM Guest

    Mark Hahn <> wrote:
    ....
    > Then I came here and asked and to my surprise I'm finding out that 100% of
    > python users want camelCase. This kind of blows away my argument against
    > it. So camelCase it will be.


    I prefer names_with_underscores.
    JCM, Apr 15, 2004
    #12
  13. Mark Hahn

    Jarek Zgoda Guest

    Mark Hahn <> pisze:

    > 1) CamelCase is more elegant, modern, more readable, and more efficient in
    > character usage.


    I use CamelCase in my ObjectPascal (Delphi, FP) code. Looks really good,
    but it's Pascal.

    > 2) Wide_names is cleaner, more readable, compatible with C, which is the
    > standard module language for Python and Prothon. Wide_names is also the
    > Python standard.


    I don't like underscores. I know, it's my problem. ;)

    > Of course in the Python world you alread have wide_names as your standard,
    > but could you for the moment pretend you were picking your standard from
    > scratch (as we are doing in the Prothon world) and give your vote for which
    > you'd prefer?


    mixedCase, like in Java (sorry). This convention makes clean distinction
    between objects and classes. I like it. Am I crazy? Yes, I am. ;)

    --
    Jarek Zgoda
    http://jpa.berlios.de/
    Jarek Zgoda, Apr 15, 2004
    #13
  14. Mark Hahn

    Joe Mason Guest

    In article <UHxfc.9323$dZ1.3740@fed1read04>, Mark Hahn wrote:
    > Of course in the Python world you alread have wide_names as your standard,
    > but could you for the moment pretend you were picking your standard from
    > scratch (as we are doing in the Prothon world) and give your vote for which
    > you'd prefer?


    Wasn't one of the Prothon design goals "when in doubt, follow Python"?

    Joe
    Joe Mason, Apr 15, 2004
    #14
  15. Mark Hahn

    Wilk Guest

    "Mark Hahn" <> writes:

    > We have agreed in Prothon that unlike Python we are going to be 100%
    > consistant in our var and method naming. We will not have run-together
    > words like iteritems, we are going to always have seperated words like
    > has_key.
    >
    > Now we are in the midst of a discussion of camelCase versus wide_names. So
    > far our arguments are:
    >
    > 1) CamelCase is more elegant, modern, more readable, and more efficient in
    > character usage.
    >
    > 2) Wide_names is cleaner, more readable, compatible with C, which is the
    > standard module language for Python and Prothon. Wide_names is also the
    > Python standard.


    Before, i used CamelCase, but now i use only wide_name because i find
    that capitals letters are a pain for the finger and the wrist. For
    example when you whant to write Q (on querty or azerty keyboard), with
    one hand you must make a gymnastic, or you will need two hands.

    The best is to try the two very quickly... I've replaced thousand of
    lines after it ! But maybe it depends how we use the keyboard...

    >
    > Of course in the Python world you alread have wide_names as your standard,


    Not everytime and i regret...

    --
    Wilk - http://flibuste.net
    Wilk, Apr 15, 2004
    #15
  16. Mark Hahn

    Jarek Zgoda Guest

    Wilk <> pisze:

    >> 2) Wide_names is cleaner, more readable, compatible with C, which is the
    >> standard module language for Python and Prothon. Wide_names is also the
    >> Python standard.

    >
    > Before, i used CamelCase, but now i use only wide_name because i find
    > that capitals letters are a pain for the finger and the wrist. For
    > example when you whant to write Q (on querty or azerty keyboard), with
    > one hand you must make a gymnastic, or you will need two hands.


    Underscore is such same pain. I cann't see any advantage.

    --
    Jarek Zgoda
    http://jpa.berlios.de/
    Jarek Zgoda, Apr 15, 2004
    #16
  17. Mark Hahn

    Jan Dries Guest

    Mark Hahn wrote:
    >
    > Then I came here and asked and to my surprise I'm finding out that 100% of
    > python users want camelCase. This kind of blows away my argument against
    > it. So camelCase it will be.


    In all fairness, you are finding out that 6 of the 8 first people to
    respond to your post prefer CamelCase. The other two didn't voice a
    clear opinion in either direction. While I'm sure that might be
    indicative of some trend, it certainly does not mean 100% of Python
    users want camelCase.

    I for one go with AM Kuchling, and prefer wide_names.

    When I started programming, I was using C (this was back in the 80's and
    early 90's) and I used to code all in wide_names. I was quite happy with
    it. Then I started writing C++ on Windows, and I gradually started using
    CamelCase and lpszqvwxHungarianNotation, primarily because MFC was using
    it. When Java came out, I followed its camelCase practice as well.
    But it wasn't until I moved to Python in 2000 that I realised how much I
    really prefer wide_names. Contrary to what others have written here, I
    find wide_names much more readable than camelCase.

    In practice though, I tend to go for whatever convention is customary in
    the environment I work in. And I have long given up the illusion you can
    be 100% consistent in these matters. That's why I rarely get involved in
    discussions like these. But when someone claims 100% of Python users
    want camelCase, I cannot but speak up.

    Regards,
    Jan
    Jan Dries, Apr 15, 2004
    #17
  18. Mark Hahn

    Wilk Guest

    Jarek Zgoda <> writes:

    > Wilk <> pisze:
    >
    >>> 2) Wide_names is cleaner, more readable, compatible with C, which is the
    >>> standard module language for Python and Prothon. Wide_names is also the
    >>> Python standard.

    >>
    >> Before, i used CamelCase, but now i use only wide_name because i find
    >> that capitals letters are a pain for the finger and the wrist. For
    >> example when you whant to write Q (on querty or azerty keyboard), with
    >> one hand you must make a gymnastic, or you will need two hands.

    >
    > Underscore is such same pain. I cann't see any advantage.


    On azerty keyboard _ is under 8 and does'nt need to press shift... I
    did'nt remember that it's diffent on qwerty.

    --
    Wilk - http://flibuste.net
    Wilk, Apr 15, 2004
    #18
  19. [Mark Hahn]

    > 1) CamelCase is more elegant, modern, more readable, and more efficient in
    > character usage.


    > 2) Wide_names is cleaner, more readable, compatible with C, which is the
    > standard module language for Python and Prothon. Wide_names is also the
    > Python standard.


    Both cannot be "more readable" simultaneously! :)

    For Python, I think legibility should be the premium concern. I wish
    Prothon shares that priority.

    Efficiency on character usage may not be that much: there was once an
    habit of removing all vowels, and a few consonants at random, from
    variable names, to spare typing; this resulted in poor legibility and
    harder maintenance. Compatibility with C should not be a concern
    either. Whatever a capital or an underscore causes the highest strain
    on the typist may not be more important than legibility either: editors
    rather than languages should address editing difficulties.

    The problem here is that legibility is not defined the same way by all
    people. People develop habits, find more legible what they saw a lot,
    and are likely to fight to protect what they learn to find good. (This
    is like smoking: children gag the first time they try it, then they get
    used to it, but the habit does not make smoking a good thing, even if
    they much like it.) My own opinion is that identifiers are better clean
    than elegant, because legibility lies on the clean side. This is why I
    prefer wide_names. But maybe wide_names are my drug and I'm wrong. I
    do know that others prefer CamelCase. I do not fully understand their
    preference, they do not really understand mine! :)

    Given full power and choice, what I would prefer is that identifiers be
    allowed to contain spaces -- would they have to be unbreakable spaces.
    That would be the most legible avenue, especially given that my editors
    and enscripters would then bold or colour Python/Prothon keywords, making
    it clear the extent of each identifier. Take this very message, save
    it in two files, then edit the first copy to replace all spaces within
    a sentence with underlines, and edit the second copy to replace all
    spaces within a sentence with the empty string, but capitalising the
    next character. My guess, which some might challenge, is that there
    will almost be a concensus that the first copy is easier to decipher.

    Legibility should be the overwhelming concern.

    --
    Fran├žois Pinard http://www.iro.umontreal.ca/~pinard
    =?iso-8859-1?Q?Fran=E7ois?= Pinard, Apr 15, 2004
    #19
  20. Mark Hahn

    Roy Smith Guest

    Jan Dries <> wrote:
    > But when someone claims 100% of Python users
    > want camelCase, I cannot but speak up.


    I hope this doesn't turn into a flame war, but I agree with Jan. One of
    my pet peeves is expressing a minority opinion ("I want X") and then
    hearing my opinion dismissed with a statement like "Everybody wants Y".
    I'm willing to be outvoted, but I sure won't stand for being ignored.

    I happen to be one of the people who expressed the majority opinion,
    i.e. in favor of DromiDaryOrthoGraphy, but it's still unfair to say that
    100% of Python users agree with me.
    Roy Smith, Apr 15, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Benson

    entering the lists against CamelCase

    John Benson, Dec 7, 2003, in forum: Python
    Replies:
    2
    Views:
    293
    John Roth
    Dec 8, 2003
  2. Mark Hahn
    Replies:
    41
    Views:
    891
    Paul Boddie
    May 27, 2004
  3. Mark Hahn
    Replies:
    20
    Views:
    572
    Mark Hahn
    Jul 13, 2004
  4. Jeff Schwab
    Replies:
    8
    Views:
    767
    James Kanze
    Mar 24, 2008
  5. Paul Butcher
    Replies:
    12
    Views:
    683
    Gary Wright
    Nov 28, 2007
Loading...

Share This Page