How to break long method name into more than one line?

Discussion in 'Python' started by Herman, Mar 11, 2012.

  1. Herman

    Herman Guest

    I am trying to stick to the rule described in the TDD book that, each
    test method name consists of the method name to be tested, inputs and
    the expected outputs. It takes up a lot of space and my company has a
    rule of limiting 79 characters (or 80) per line. I found that
    def abcdeef\
    dddaaa(self):
    pass

    does not work, but
    def \
    abcsajfoijfiawifoiwejfoi(self):
    pass

    works. Is this the only way to do it?
    Herman, Mar 11, 2012
    #1
    1. Advertising

  2. Herman

    Roy Smith Guest

    In article <>,
    Herman <> wrote:

    > I am trying to stick to the rule described in the TDD book that, each
    > test method name consists of the method name to be tested, inputs and
    > the expected outputs. It takes up a lot of space and my company has a
    > rule of limiting 79 characters (or 80) per line. I found that
    > def abcdeef\
    > dddaaa(self):
    > pass
    >
    > does not work, but
    > def \
    > abcsajfoijfiawifoiwejfoi(self):
    > pass
    >
    > works. Is this the only way to do it?


    Arrrrrrrrhhhggggg. If you can't fit a test method name into 79
    characters, you're doing somthing wrong. Just for fun, I found all the
    test methods in the project I'm working on and sorted them by length.
    Here's the top of the list:

    $ find . -name 'test*py' | xargs grep -h 'def *test' | sort | uniq |
    awk '{print length($0), $0}' | sort -nr
    55 def test_update_name_changes_dasherized_name(self):
    51 def test_get_followers_with_no_followers(self):
    50 def test_update_station_song_adds_false(self):
    50 def test_anonymous_get_user_collections(self):
    49 def test_wrong_user_update_should_fail(self):
    49 def test_login_with_email_and_password(self):
    47 def test_unknown_station_returns_404(self):
    47 def test_login_failure_with_facebook(self):
    47 def test_get_follows_with_no_follows(self):
    46 def test_station_by_dasherized_name(self):
    46 def test_nonexistent_recent_station(self):
    46 def test_new_user_with_display_name(self):
    46 def test_auto_connect_with_facebook(self):
    46 def test_anonymous_created_stations(self):
    45 def test_no_php_fatal_error_in_log(self):
    45 def test_get_only_songza_followers(self):
    45 def test_anonymous_vote_transition(self):
    44 def test_non_ascii_global_station(self):
    44 def test_global_station_not_found(self):
    44 def test_gallery_create_duplicate(self):
    44 def test_anonymous_listen_history(self):

    and so on down to the wonderfully terse:

    21 def test_x(self):

    which I'm assuming actually makes sense in the context of the TestCase
    class it belongs to. At least I hope it does :)

    The examples above are a reasonable upper limit on the verbosity you
    should be shooting for, IMHO.
    Roy Smith, Mar 11, 2012
    #2
    1. Advertising

  3. On Sun, 11 Mar 2012 11:53:45 -0700, Herman wrote:

    > I am trying to stick to the rule described in the TDD book that, each
    > test method name consists of the method name to be tested, inputs and
    > the expected outputs.


    *The* TDD book? There's only one? Surely not.

    That rule sounds utterly impractical. I can't think of anything to
    recommend it. Like any other function, method or class, tests should have
    meaningful names, but reading the name alone should not necessarily tell
    you *everything* about the function.

    We have "len", not "len_sequence_or_mapping_int", and similarly it is
    perfectly reasonable to have "test_len_empty" rather than
    "test_len_emptylist_emptystr_emptyunicode_emptydict_emptyset_emptytuple_zero".

    I expect that naming rule was invented by either people who have heard of
    test driven development, but never actually done it, or by people so
    anally-retentive that if they make seven short car trips over an hour,
    they check the tyre pressure, oil and water seven times because "the
    manual says to check before *every* trip".

    No offence.

    My advice is to moderate the naming convention of your tests with a good
    dose of common sense and aim for names which are readable rather than
    names that contain everything including the kitchen sink. Imagine you are
    in a technical meeting with some of your fellow programmers, and need to
    ask for help with a failing test. Imagine saying the name of the test
    aloud in a sentence. Does it add clarity to the discussion, or obfuscate
    it?

    People's short term memory can only hold so much (allegedly "seven plus
    or minus two"), and if the name itself hits that limit, you leave nothing
    left for the rest of the sentence.

    http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two

    Names should be practically, rather than conforming to some naming rule
    that hurts readability and obfuscates the tests.


    > It takes up a lot of space and my company has a
    > rule of limiting 79 characters (or 80) per line. I found that def
    > abcdeef\
    > dddaaa(self):
    > pass
    >
    > does not work, but
    > def \
    > abcsajfoijfiawifoiwejfoi(self):
    > pass
    >
    > works. Is this the only way to do it?


    Yes. You can't split tokens over multiple lines, or put any whitespace
    between them.


    --
    Steven
    Steven D'Aprano, Mar 12, 2012
    #3
  4. Herman

    Roy Smith Guest

    In article <4f5d4390$0$29891$c3e8da3$>,
    Steven D'Aprano <> wrote:

    > You can't split tokens over multiple lines, or put any whitespace
    > between them.


    Well, if you truly wanted to be perverse, you could write some kind of
    decorator:

    @make_long_named_test_method('some',
    'very',
    'long',
    'list',
    'of',
    'token',
    'fragments')
    def x(self):
    blah, blah, blah

    which creates a "test_some_very_long_list_of_token_fragments" method.
    But it would be a lot easier to just use sane method names.
    Roy Smith, Mar 12, 2012
    #4
  5. off topic observation...

    On 12 Mar 2012 00:30:08 GMT, Steven D'Aprano
    <> declaimed the following in
    gmane.comp.python.general:


    > I expect that naming rule was invented by either people who have heard of
    > test driven development, but never actually done it, or by people so
    > anally-retentive that if they make seven short car trips over an hour,
    > they check the tyre pressure, oil and water seven times because "the
    > manual says to check before *every* trip".
    >

    By which time they find they have to add air, oil, and water as: the
    pressure gauge usage lets out some air each time; they've wiped a few
    drops of oil onto a rag each time; and the radiator was still
    hot&pressurized such that they got an "overfull" result.
    --
    Wulfraed Dennis Lee Bieber AF6VN
    HTTP://wlfraed.home.netcom.com/
    Dennis Lee Bieber, Mar 12, 2012
    #5
  6. On Tue, Mar 13, 2012 at 3:24 AM, Dennis Lee Bieber
    <> wrote:
    > On 12 Mar 2012 00:30:08 GMT, Steven D'Aprano
    > <> declaimed the following in
    > gmane.comp.python.general:
    >> I expect that naming rule was invented by either people who have heard of
    >> test driven development, but never actually done it, or by people so
    >> anally-retentive that if they make seven short car trips over an hour,
    >> they check the tyre pressure, oil and water seven times because "the
    >> manual says to check before *every* trip".
    >>

    >        By which time they find they have to add air, oil, and water as: the
    > pressure gauge usage lets out some air each time; they've wiped a few
    > drops of oil onto a rag each time; and the radiator was still
    > hot&pressurized such that they got an "overfull" result.


    In defense of such rules: There's a period in every new programmer's
    life when it helps to learn a whole lot of principles; and if he's
    working on some collaborative project, rules are the easiest way to
    demand such behavior. Later on, you learn how and when it's safe to
    break the rules (and/or how to deal with rule conflicts), but the
    rules still have value. Just never treat them as laws of physics (in
    Soviet Physics, rules break you!).

    ChrisA
    Chris Angelico, Mar 12, 2012
    #6
  7. Chris Angelico wrote:
    > Just never treat them as laws of physics (in
    > Soviet Physics, rules break you!).
    >
    > ChrisA
    >


    hum ...
    I wonder how this political message is relevant to the OP problem.

    JM
    Jean-Michel Pichavant, Mar 13, 2012
    #7
  8. On Tue, Mar 13, 2012 at 9:30 PM, Jean-Michel Pichavant
    <> wrote:
    > Chris Angelico wrote:
    >>
    >> Just never treat them as laws of physics (in
    >> Soviet Physics, rules break you!).

    >
    > hum ...
    > I wonder how this political message is relevant to the OP problem.


    Ehh, it's a reference to the "in Soviet Russia" theme of one-liners.
    You don't break the laws of physics, they break you. My point is that
    rules about function names etc are *not* inviolate, and should be
    treated accordingly.

    ChrisA
    Chris Angelico, Mar 13, 2012
    #8
    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. Dave
    Replies:
    6
    Views:
    561
  2. Vince C.
    Replies:
    6
    Views:
    727
    James Kanze
    Jul 18, 2007
  3. Merciadri Luca
    Replies:
    4
    Views:
    809
  4. Steven D'Aprano
    Replies:
    0
    Views:
    90
    Steven D'Aprano
    Dec 23, 2013
  5. Replies:
    3
    Views:
    82
    Gary Herron
    Dec 23, 2013
Loading...

Share This Page