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

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

Re: for / while else doesn't make sense

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

Contents

  Re: for / while else doesn't make sense alister <alister.ware@ntlworld.com> - 2016-06-10 11:18 +0000
    Re: for / while else doesn't make sense Marko Rauhamaa <marko@pacujo.net> - 2016-06-10 15:31 +0300
      Re: for / while else doesn't make sense alister <alister.ware@ntlworld.com> - 2016-06-10 13:06 +0000
      Re: for / while else doesn't make sense Ian Kelly <ian.g.kelly@gmail.com> - 2016-06-10 08:00 -0600
        Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-06-11 00:27 +1000
          Re: for / while else doesn't make sense Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-11 13:17 +1200
        Re: for / while else doesn't make sense Marko Rauhamaa <marko@pacujo.net> - 2016-06-10 19:13 +0300

#109780 — Re: for / while else doesn't make sense

On Thu, 09 Jun 2016 18:19:23 +1000, Steven D'Aprano wrote:

> On Thursday 09 June 2016 10:34, Lawrence D’Oliveiro wrote:
> 
>> In my undergraduate Comp Sci classes, we used to discuss arbitrary
>> rules like limiting functions to n lines. With real-world experience,
>> it soon became clear that such rules were a waste of time. A function
>> should be just as big as it needs to be, no more, no less. The same
>> with a class, or a module. Or whatever other constructs your language
>> may have.
> 
> The opposite of "arbitrary limits" is not "no limits".
> 
> An arbitrary limit like "500 lines is the maximum size a function may
> be" is clearly arbitrary and not very helpful. (Also too high.)
> 
> Better is to understand that there is no hard cut-off between
> "acceptable" and "too long", but we can still judge that all else being
> equal, long functions are worse than short functions.
> 
> The real problem is complexity of functions. The more complex they are,
> the harder they are to write correctly, and the harder to maintain, and
> the more likely that they have bugs.
> 
> The length of a function is a very crude measure of complexity, but it
> *is* a measure of complexity, and people are right to look at long
> functions as a code smell and a sign that the function probably does too
> much, or is badly written,
> or that it could do with some refactoring to simplify it. Not in *every*
> case, but I've never yet seen a long (> 200 lines) function that wasn't
> improved by refactoring or splitting.



Or more simply a hard fixed RULE (MUST be less than X lines) is Bad.

a flexible GUIDELINE on the other hand is reasonable.

after all an efficient function could be be X=1 lines, abriatrily spliting 
this could make the final function less readable & possibly even longer 
in total.
 


-- 
Puns are little "plays on words" that a certain breed of person loves to
spring on you and then look at you in a certain self-satisfied way to
indicate that he thinks that you must think that he is by far the 
cleverest
person on Earth now that Benjamin Franklin is dead, when in fact what you
are thinking is that if this person ever ends up in a lifeboat, the other
passengers will hurl him overboard by the end of the first day even if 
they
have plenty of food and water.
		-- Dave Barry, "Why Humor is Funny"

[toc] | [next] | [standalone]

#109782

alister <alister.ware@ntlworld.com>:

> Or more simply a hard fixed RULE (MUST be less than X lines) is Bad.

It's not X lines, it's "you must see the whole function at once."

If your display can show 1,500 lines at once, that's your limit. Mine
shows 70.

> a flexible GUIDELINE on the other hand is reasonable.

There are rare exceptions to every rule.

> after all an efficient function could be be X=1 lines, abriatrily
> spliting this could make the final function less readable & possibly
> even longer in total.

Splitting functions requires taste and skill but, when done properly,
guarantees easier reading and higher quality. As you refactor your
function, you notice clumsy and questionable idioms and end up tidying
the logic up in the process.


Marko

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

#109783

On Fri, 10 Jun 2016 15:31:11 +0300, Marko Rauhamaa wrote:

> alister <alister.ware@ntlworld.com>:
> 
>> Or more simply a hard fixed RULE (MUST be less than X lines) is Bad.
> 
> It's not X lines, it's "you must see the whole function at once."
> 
> If your display can show 1,500 lines at once, that's your limit. Mine
> shows 70.
> 
>> a flexible GUIDELINE on the other hand is reasonable.
> 
> There are rare exceptions to every rule.
> 
>> after all an efficient function could be be X=1 lines, abriatrily
>> spliting this could make the final function less readable & possibly
>> even longer in total.
> 
> Splitting functions requires taste and skill but, when done properly,
> guarantees easier reading and higher quality. As you refactor your
> function, you notice clumsy and questionable idioms and end up tidying
> the logic up in the process.
> 
> 
> Marko

you think I am arguing?
i am not (excpet possibly on symantics)

your "you must see the whole function on one page" stipulation should be 
treated as guidance & not a rule
preferably it should read "You 'SHOULD' be able to see the whole function 
on one page.

and as you quite rightly state there are always exceptions as enshrined 
in the zen

"Practicality beats Purity"



-- 
Must I hold a candle to my shames?
		-- William Shakespeare, "The Merchant of Venice"

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

#109786

On Jun 10, 2016 6:37 AM, "Marko Rauhamaa" <marko@pacujo.net> wrote:
>
> alister <alister.ware@ntlworld.com>:
>
> > Or more simply a hard fixed RULE (MUST be less than X lines) is Bad.
>
> It's not X lines, it's "you must see the whole function at once."
>
> If your display can show 1,500 lines at once, that's your limit. Mine
> shows 70.

I disagree on that point. For a typical-size display, it's a reasonable
guideline. But just because your 1500-line function fits in a single screen
does not make it readable. In particular, if the function is deeply nested,
then it quickly becomes difficult to discern which code aligns with which.

A similar principle informs us that 70-100 columns is a reasonable line
length limit for readability even if your display can fit much more.

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

#109789

On Sat, 11 Jun 2016 12:00 am, Ian Kelly wrote:

> On Jun 10, 2016 6:37 AM, "Marko Rauhamaa" <marko@pacujo.net> wrote:

>> If your display can show 1,500 lines at once, that's your limit. Mine
>> shows 70.
> 
> I disagree on that point. For a typical-size display, it's a reasonable
> guideline. But just because your 1500-line function fits in a single
> screen does not make it readable. 

I disagree. I have a 2000 inch monitor, and by using a narrow proportional
font set to 5pt, I can display the entire Python standard library including
tests on screen at once. Then it's just a matter of using my trusty 4"
reflecting telescope to zoom in on any part of the screen I like. This is
much more convenient than opening a single file at a time, or using a
tabbed interface, it is much more efficient to just swivel the telescope
and jump to the correct part of the code, and it rarely takes me more than
ten or fifteen minutes to find it.

And I can read the code in perfect clarity, provided I don't nudge or touch
the telescope in any way, or breathe too hard. Apart from "rn" which tends
to look like an "m", and its a bit hard to tell the difference between 0
and 0 or 1 I and l, or S and 5, and to be honest periods and commas are
completely invisible, but that's a small price to pay for the extra
efficiency of having all 641 thousand lines of code on screen all at once.



-- 
Steven

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

#109810

Steven D'Aprano wrote:
> I have a 2000 inch monitor, and by using a narrow proportional
> font set to 5pt, I can display the entire Python standard library including
> tests on screen at once. Then it's just a matter of using my trusty 4"
> reflecting telescope to zoom in on any part of the screen I like.

You may think you're joking, but this sounds remarkably
similar to microfiche...

http://www.wisegeek.org/what-is-microfiche.htm

-- 
Greg

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

#109796

Ian Kelly <ian.g.kelly@gmail.com>:

> On Jun 10, 2016 6:37 AM, "Marko Rauhamaa" <marko@pacujo.net> wrote:
>> If your display can show 1,500 lines at once, that's your limit. Mine
>> shows 70.
>
> I disagree on that point. For a typical-size display, it's a
> reasonable guideline.

The point I'm making is that if I'm accusing you for writing functions
that are too long (they don't fit on my editor window), you can counter
that they fit perfectly well on yours.

No-one has 1,500-line editor windows, I suppose. However, screen sizes
have been going up and some people prefer to turn their screens into
portrait mode (tried it, made my neck hurt). Years back, I had 24 lines
on the screen. As screen sizes have gone up, I've allowed for longer
functions as well. Now I'm at 70. Of course, most functions tend to be
much shorter.


Marko

[toc] | [prev] | [standalone]

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

csiph-web