"tamouse mailing lists" wrote in message
news:CAHUC_t__sW-_YHRw4n4UQR-fA46+CeBuNzGeHboaaTrafLA-2g@xxxxxxxxxxxxxx...
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.
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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
