Re: Re: Function size

"tamouse mailing lists" wrote in message news:CAHUC_t__sW-_YHRw4n4UQR-fA46+CeBuNzGeHboaaTrafLA-2g@mail.gmail.com...

On Tue, May 29, 2012 at 2:52 AM, Tony Marston <tony@marston-home.demon.co.uk> 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.

I have been maintaining other people's code, which have been written to many different standards of varying quality, for many years.

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.

I *never* have huge numbers of lines between a block beginning and end. Even if I did my IDE can quickly find the other end of the block for me.

If you will never have your code maintained by anyone else, or collaborate with anyone else, feel free to do what you want.

My code has been available in an open source framework for over 6 years, and I have never received any complaints on the readability of my code, only compliments.

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.

Ah-ha! So someone agrees with me on that point after all.

- 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?

I am *NOT* going to change my IDE just to suit *YOUR* preferences.

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.

I will only follow standards which have a genuine purpose and a genuine benefit. I will *NOT* follow any which I consider to be arbitrary, artificial and pointless. There is *NO* limit to the number of lines in a function/method, and there is *NO* limit on the number of methods within a class. The only thing that matters is that the code is readable and maintainable. If some functions overflow the current screen then LEARN TO USE THE MOUSE WHEEL! That is what is was invented for in the first place. I will *NOT* make my code more difficult to read by creating a huge number of artificially small functions.

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.

I *DO* care, which is why I write code which is readable and maintainable. -- Tony Marston http://www.tonymarston.net http://www.radicore.org