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 once. 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 efficiency. 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 -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
