Re: Function size
| From: | Tedd Sperling | Date: | Thu, 24 May 2012 14:52:31 +0000 |
| Subject: | Re: Function size | ||
| References: | 1 2 3 4 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-317990@lists.php.net to get a copy of this message | ||
On May 23, 2012, at 3:49 PM, Ashley Sheridan wrote:
>
> I'm of the same mind. Generally I'll split a function if I'm reusing more than a
> couple of lines of code. I only split a "large" function if it's actually doing
> several things, if it happens to need 200 lines to perform one 'step' then I'll leave
> it as is. While I do prefer my functions to fit into a single 'screen', it rarely happens
> quite like that, because I move from screen to screen with different resolutions, so there's no
> constant limit for me.
>
> As a rough example, on a random selection of 27 functions taken from a controller on a site I
> worked on I get these general statistics:
>
> Functions: 27
> Mean lines: 22.5
> Mode lines: 3
> Max lines: 218
>
> The function with 218 lines is a large switch, and it doesn't make sense to do it any
> other way, because it would actually end up less readable.
I see you and I are like minds in many ways.
I had one large switch block that had 255 different cases. Oddly enough I was parsing a
"Tiger" data file (USGS survey data) that contained 255 different record types. Each
record type required a different function to parse the data and render it's portion of the
overall map. That lead to me create a linked-list that held the memory addresses of both data and
function. That way simply accessing the linked list coupled data to function and drew the map. It
was neat.
I find it also neat, while I'm not an expert on the subject, eliminating the need for
'switch' and 'if' statements via extending classes in OO.
Shiplu provided a link, which I found interesting:
http://www.youtube.com/watch?v=4F72VULWFvc
It showed how one can eliminate such conditionals, but at the same time it massively increased the
code to preform 1 + 2 * 3. :-)
And to others, I don't need comment on how I missed the point -- I didn't.
Cheers,
tedd
_____________________
tedd@sperling.com
http://sperling.com