On Thu, 2012-05-24 at 15:48 -0500, tamouse mailing lists wrote:
> 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.
With the odd exception being where code is more readable in a longer
format, as seen with my and several others examples of long functions
that rely heavily on switches.