On Tue, May 29, 2012 at 2:52 AM, Tony Marston <tony@xxxxxxxxxxxxxxxxxxxxxxxx> 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. You obviously haven't spent much time maintaining other people's code. There is a point: if you are unfamiliar with code, wading through screens and screens of a function to find things like block beginning/ends makes for difficult time finding places where changes need to be made. If you will never have your code maintained by anyone else, or collaborate with anyone else, feel free to do what you want. > > 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. Yes, you do, which is also considered a hallmark of good design. > - 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. Also correct; this is a key point in making sure your scripts are maintainable. > - 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. May I suggest an editor/IDE that lets you navigate to functions directly, then? > 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. There are counterbalancing things as well. If the only aspect of one's coding standards are "make it fit on one screen" then yes, you might see someone idiotic enough to do that. However, a good set of coding standards includes things which will prevent this, such as not stacking code like that. > 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. The rules of thumb for coding standards are for maintainability, primarily, so throwing up strawmen to try to weasel out of an idea is pretty specious. If you do not care about how much time it takes to fix defects in other people's code, then I hope you remain a solitary programmer and don't expect anyone else to use your code, otherwise, you are in the wrong job. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
