On Thu, 2012-05-24 at 15:48 -0500, tamouse mailing lists wrote: > On May 23, 2012 9:14 AM, "Tedd Sperling" <tedd@xxxxxxxxxxxx> 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.sperling@xxxxxxxxx > > 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. -- Thanks, Ash http://www.ashleysheridan.co.uk
