On May 23, 2012 9:14 AM, "Tedd Sperling" <t...@sperling.com> wrote:
> Hi gang:
> On May 21, 2012, at 8:32 PM, tamouse mailing lists wrote:
> >  A rule of thumb is no more than 50 lines per
> > function, most much less. Back in the day when we didn't have nifty
> > gui screens and an 24 line terminals (yay green on black!), if a
> > function exceeded one printed page, it was deemed too long and marked
> > for refactoring.
> You hit upon a theory of mine -- and that is our functions grow in size
up to our ability to view them in their totality. When our functions get
beyond that limit, we tend to refactor and reduce.
> I know from the last several decades of programming, my functions have
increased in number of lines. But, they have reached a limit that limit is
generally about the number of lines I can read in half of my monitor's
height. This of course, is dependent on monitor resolution, font-size, and
how far I am sitting from the monitor. But I think this is a natural and
physical limit that we don't normally recognize. I can cite studies that
support my theory.
> It would be an interesting survey to ask programmers to review their code
and provide the average number of lines in their functions AND how many
lines of code their monitor's can display. In other words, look at your
editor; count the number of lines your monitor can display; estimate the
number of lines in your average function; and report the findings.  For
example, mine is about half -- my monitor can display 55 lines of code and
my average function is around 25 lines. YMMV.
> Interesting, yes?
> Cheers,
> tedd
> _____________________
> tedd.sperl...@gmail.com
> http://sperling.com

Yes, I think that is *exactly* the criterion-- not a mystery or an emergent
thing, really, was a pretty expicit reasoning--being able to see/scan the
entire function on one page (or now in one screenful) makes it much easier
to see what happens in the function, where blocks open/close, and it forces
one to break up code into logical units.

Reply via email to