style guideline for naming variables?

Discussion in 'Python' started by John Salerno, Mar 17, 2006.

  1. John Salerno

    John Salerno Guest

    After reading the PEP, I'm still not quite sure if there is a
    recommended (or widely preferred) method of naming variables. Here are
    the relevant bits:

    > Global Variable Names
    >
    > (Let's hope that these variables are meant for use inside one module
    > only.) The conventions are about the same as those for functions.
    >
    > Modules that are designed for use via "from M import *" should use the
    > __all__ mechanism to prevent exporting globals, or use the the older
    > convention of prefixing such globals with an underscore (which you might
    > want to do to indicate these globals are "module non-public").
    >
    > Function Names
    >
    > Function names should be lowercase, with words separated by underscores
    > as necessary to improve readability.
    >
    > mixedCase is allowed only in contexts where that's already the
    > prevailing style (e.g. threading.py), to retain backwards compatibility.
    >
    > Method Names and Instance Variables
    >
    > Use the function naming rules: lowercase with words separated by
    > underscores as necessary to improve readability.
    >
    > Use one leading underscore only for non-public methods and instance
    > variables.
    >
    > To avoid name clashes with subclasses, use two leading underscores to
    > invoke Python's name mangling rules.
    >
    > Python mangles these names with the class name: if class Foo has an
    > attribute named __a, it cannot be accessed by Foo.__a. (An insistent
    > user could still gain access by calling Foo._Foo__a.) Generally, double
    > leading underscores should be used only to avoid name conflicts with
    > attributes in classes designed to be subclassed.
    >
    > Note: there is some controversy about the use of __names (see below).


    It refers to instance variables, which I assume includes all variables
    that aren't global, and the suggestion is to follow function
    conventions, which would be this:

    some_function

    But this seems awkward to me. someFunction seems nicer, but it is
    specifically mentioned not to do this for new code.

    So I'm just curious how other people handle the multiword situation.
    Underscores, or Pascal case?
     
    John Salerno, Mar 17, 2006
    #1
    1. Advertising

  2. John Salerno

    John Salerno Guest

    John Salerno wrote:

    > some_function
    >
    > But this seems awkward to me. someFunction seems nicer


    Sorry, I was asking about variables but used a function example. But
    really I'm asking about any situation where you might want to use
    multiple words (except for classes, which is recommended to use Camel
    case, and that seems fine).
     
    John Salerno, Mar 17, 2006
    #2
    1. Advertising

  3. John Salerno

    Duncan Smith Guest

    John Salerno wrote:
    > After reading the PEP, I'm still not quite sure if there is a
    > recommended (or widely preferred) method of naming variables. Here are
    > the relevant bits:
    >
    >> Global Variable Names
    >>
    >> (Let's hope that these variables are meant for use inside one
    >> module
    >> only.) The conventions are about the same as those for functions.
    >>
    >> Modules that are designed for use via "from M import *" should
    >> use the
    >> __all__ mechanism to prevent exporting globals, or use the the
    >> older
    >> convention of prefixing such globals with an underscore (which
    >> you might
    >> want to do to indicate these globals are "module non-public").
    >>
    >> Function Names
    >>
    >> Function names should be lowercase, with words separated by
    >> underscores
    >> as necessary to improve readability.
    >>
    >> mixedCase is allowed only in contexts where that's already the
    >> prevailing style (e.g. threading.py), to retain backwards
    >> compatibility.

    >
    >>

    >
    >> Method Names and Instance Variables
    >>
    >> Use the function naming rules: lowercase with words separated by
    >> underscores as necessary to improve readability.
    >>
    >> Use one leading underscore only for non-public methods and instance
    >> variables.
    >>
    >> To avoid name clashes with subclasses, use two leading
    >> underscores to
    >> invoke Python's name mangling rules.
    >>
    >> Python mangles these names with the class name: if class Foo has an
    >> attribute named __a, it cannot be accessed by Foo.__a. (An
    >> insistent
    >> user could still gain access by calling Foo._Foo__a.)
    >> Generally, double
    >> leading underscores should be used only to avoid name conflicts
    >> with
    >> attributes in classes designed to be subclassed.
    >>
    >> Note: there is some controversy about the use of __names (see
    >> below).

    >
    >
    > It refers to instance variables, which I assume includes all variables
    > that aren't global, and the suggestion is to follow function
    > conventions, which would be this:
    >
    > some_function
    >
    > But this seems awkward to me. someFunction seems nicer, but it is
    > specifically mentioned not to do this for new code.
    >
    > So I'm just curious how other people handle the multiword situation.
    > Underscores, or Pascal case?


    SomeClass

    someFunction

    some_variable

    FWIW

    Duncan
     
    Duncan Smith, Mar 18, 2006
    #3
    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. Vyom

    macro style guideline

    Vyom, Nov 21, 2004, in forum: C Programming
    Replies:
    7
    Views:
    328
    Dan Pop
    Nov 23, 2004
  2. lovecreatesbeauty

    Redundant behavior in coding guideline

    lovecreatesbeauty, Oct 27, 2005, in forum: C Programming
    Replies:
    0
    Views:
    406
    lovecreatesbeauty
    Oct 27, 2005
  3. lovecreatesbeauty

    Redundant behavior in coding guideline

    lovecreatesbeauty, Oct 27, 2005, in forum: C Programming
    Replies:
    2
    Views:
    335
    Netocrat
    Oct 27, 2005
  4. lovecreatesbeauty
    Replies:
    17
    Views:
    602
    Jordan Abel
    Jan 1, 2006
  5. Paul McGuire

    Is PEP-8 a Code or More of a Guideline?

    Paul McGuire, May 27, 2007, in forum: Python
    Replies:
    52
    Views:
    1,026
    Ben Finney
    Jun 1, 2007
Loading...

Share This Page