Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #21500 > unrolled thread

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

Back to article view | Back to comp.lang.python

Contents

  How to break long method name into more than one line? Herman <sorsorday@gmail.com> - 2012-03-11 11:53 -0700
    Re: How to break long method name into more than one line? Roy Smith <roy@panix.com> - 2012-03-11 15:11 -0400
    Re: How to break long method name into more than one line? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-12 00:30 +0000
      Re: How to break long method name into more than one line? Roy Smith <roy@panix.com> - 2012-03-11 20:43 -0400
      Re: How to break long method name into more than one line? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-03-12 12:24 -0400
      Re: How to break long method name into more than one line? Chris Angelico <rosuav@gmail.com> - 2012-03-13 08:59 +1100
      Re: How to break long method name into more than one line? Jean-Michel Pichavant <jeanmichel@sequans.com> - 2012-03-13 11:30 +0100
      Re: How to break long method name into more than one line? Chris Angelico <rosuav@gmail.com> - 2012-03-13 21:35 +1100

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

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?

[toc] | [next] | [standalone]

#21502

In article <mailman.571.1331492028.3037.python-list@python.org>,
 Herman <sorsorday@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

#21515

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

[toc] | [prev] | [next] | [standalone]

#21516

In article <4f5d4390$0$29891$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> 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.

[toc] | [prev] | [next] | [standalone]

#21540

off topic observation...

On 12 Mar 2012 00:30:08 GMT, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> 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
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#21549

On Tue, Mar 13, 2012 at 3:24 AM, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:
> On 12 Mar 2012 00:30:08 GMT, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> 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

[toc] | [prev] | [next] | [standalone]

#21556

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

[toc] | [prev] | [next] | [standalone]

#21557

On Tue, Mar 13, 2012 at 9:30 PM, Jean-Michel Pichavant
<jeanmichel@sequans.com> 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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web