On Tue, May 29, 2012 at 08:52:46AM +0100, Tony Marston wrote: > 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. > > I think the idea of setting an arbitrary limit on the number of lines that a > function should contain is quite ludicrous and something which I will > completely ignore. If a function requires a hundred or more lines then so be > it. 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 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. > - 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. OMG in alpha order?! At best, I might group them together by function type, with some comment notation in the file. But not alpha order. I prefer not to have "forward declares" in my files, so I generally arrange functions so that those called by other functions later are defined before they're called. (Probably a holdover from my C days; PHP doesn't care.) No offense. I never even thought about arranging functions in alphabetical order. But I don't think I'd do it. > - when browsing through the code you have to keep jumping to another > function, and then returning to where you came from. > > I don't know about you, but I would rather use the scroll wheel on my mouse > than keep jumping from one position in the file to another. > > 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. I think a lot of coders try to be kewler than the next 18 guys who are gonna have to look at the code, so they use a lot of "compression" techniques to reduce LOC. Plus, they're lazy. I'd rather see everything with lots of spaces and plenty of comments and blank lines. Especially since I'm sometimes that 18th guy to look at the code. Paul -- Paul M. Foster http://noferblatz.com http://quillandmouse.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
