On 23 May 2012, at 15:14, Tedd Sperling 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?

It's a theory, yes, and for many people it may be valid, but it's not for me. 
The resolution of your screen; the size of your font; the colour scheme you 
use. These should not be a factor in the way you write your code. If they are 
then you'll be making decisions for all the wrong reasons.

The art of software development is in taking a problem, breaking it up in to 
bite-size chunks, and putting those chunks together to form a practical 
solution. Anyone who considers themselves a "better" programmer because their 
functions are large due to their ability to handle large functions needs to 
keep their ego in check. Mental capacity has nothing to do with it.

My philosophy for functions is simple... a function does one well-defined, 
discrete task, and it does it well. The inputs are clearly specified, and the 
potential outputs/exceptions are fully understood. Sound familiar? These 
requirements make it incredibly easy to write unit tests for the code.

The number of times a function is used does not enter my field of interest. 
It's irrelevant, as is the number of lines in each function. Following this 
philosophy does naturally lead to fairly small functions, but as you move up 
the levels of abstraction they tend to grow larger. For PHP, I consider code in 
a file that's not within a function to be a function in itself, and the same 
philosophy applies.

I wasn't going to respond to this thread because I think it's a largely 
ridiculous topic, but some of the responses have scared me. Sir Cummings 
(hopefully) sarcastic response about using a 5px font size demonstrated how 
daft it is to base function size on how much code you can see on the screen at 

Looking at the stats for your code is meaningless, and it's particularly 
meaningless if you're looking at lines rather than statements, but even then it 
lacks sufficient meaning to be worthwhile.

Shiplu posted a great video on using polymorphism to properly model different 
behaviours of a base type, and that's great, but for PHP you need to factory in 
the sizeable speed difference between using a switch statement and using 
objects. You should never let the elegance of a solution take priority over 

Tony had some curious comments...

On 29 May 2012, at 08:52, Tony Marston wrote:
> The only reason to take a block of code and put it into its own function
> is when that code is likely to be called more than once so that it conforms
> to the DRY principle. If it is only ever used in one place then there is no
> point.

The DRY principle -- a great principle to observe. However, having functions 
that are only used once does not violate the DRY principle, in fact in some 
ways it makes it easier to adhere to it. Also, there is a point to pulling out 
code that's only used once into a separate function, it's called unit testing, 
and if you're not doing that then YOU are in the wrong job :)

KISS is more important than DRY in my opinion, and KISS should naturally lead 
to DRY (in most cases).

> The problems I have with creating lots of small used-only-once functions is
> as follows:
> - you have to create a meaningful name for each function.

Oh, dear $DEITY, the hardship. Hmm, then again, naming my functions properly 
will help you with your DRY goals. Hmm.

Seriously tho, you've refactored that code into its own function BECAUSE it's 
doing a discrete task. Naming it should not be difficult if you're refactoring 
it for the right reasons.

> - all those functions should be arranged in alphabetical order within their
> containing file - having them in a random sequence makes it difficult to
> find the one you want.

Should they? Why should they? I have never organised my functions in 
alphabetical order! If you're having trouble locating a function then you need 
a better editor. One with a decent search function should suffice; searching 
for "function myfunction" usually works for me. If you're stuck I'd recommend 
you check out Sublime Text 2 -- it's awesome, and has a very fast multi-file 
search facility!

> - when browsing through the code you have to keep jumping to another
> function, and then returning to where you came from.

My my, you do have a hard life. But, seriously...?

> Another problem I have encountered in the past with such an idea is that it
> encourages a stupid programmer to decrease the number of lines of code by
> compressing as many statements as possible into a single line, which then
> makes the code less easy to read and understand. This is much worse than
> having more than 20 lines in a function.

Thanks for this, it naturally segues me into a brief summary of my thoughts...

1) First and foremost, if the programmers you're working with really think like 
that, change them. I don't care if that means changing jobs -- trust me, you'll 
be better off in the long run.

2) Education is what turns a "stupid" programmer into a "better" programmer. Be 
an educator and make the world that little bit better.

3) Specifying a maximum number of lines for functions is dumb.

4) Specifying a maximum number of statements for functions is slightly less 
dumb but it's still up there.

5) Use your common sense. If a function is doing more than one job, break it 
up. Obviously by that logic you can break it up so that each function contains 
a single line, but that's daft. With some experience it should become obvious 
where you should draw the line in any given situation.

6) When you add or modify code, evaluate whether you should refactor it. Code 
is fluid and you should approach it as such (a cup of water is easier to 
control than a stream, which is easier to control than a river, which is easier 
to control than a sea).

7) Don't measure meaningless stuff. Measure stuff that matters. The average 
number of lines or statements in your functions doesn't matter. Ever.

> Whether a file contains 10 functions of 100 lines each, or 100 functions of
> 10 lines each, you still end up with 1000 lines of code. If you do not have
> the mental capacity to deal with a 100-line function then you are in the
> wrong job.

If you think being able to deal with a large block of code makes you a better 
programmer, YOU are in the wrong job. A good programmer, in my opinion, knows 
that the simpler and more discrete each block of code is the less room there is 
for errors. An excellent programmer knows that 100-line functions are generally 
impossible to adequately unit test.

The bottom line is to use your common sense rather than sticking to some 
arbitrarily prescribed, measurable target.


Stuart Dallas
3ft9 Ltd
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to