Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re^5: Seeking Best Practices - does your company follow a standard?

by JavaFan (Canon)
on May 06, 2010 at 22:30 UTC ( [id://838800]=note: print w/replies, xml ) Need Help??


in reply to Re^4: Seeking Best Practices - does your company follow a standard?
in thread Seeking Best Practices - does your company follow a standard?

That you have to imagine cases where 2000 line subs are preferred, tells me exactly how often such cases really occur: almost never.
Right. And that's the point, ain't it. "Almost never" isn't the same as "never". And that doesn't answer my question. How are you going to codify that in a coding standard? We have established that you think 2000 is too much. How about 1999? How about 1998? ... How about 5? How about 4? How about 3? Where do you draw the line? And how do you justify that exactly the limit is ok, but one line more isn't?
In 10 years of coding Perl for a living, I have never seen a 2K LOC subroutine that wasn't 90% scaffolding that should have been abstracted away into other modules, with the remaining 200 lines doing 5 to 10 different things that should have been tucked into their own, nicely named subroutine.
I don't have that awesome memory. In fact, I can't even remember of the subroutines I saw earlier this week how much "scaffolding" there was - let alone remembering them over a 10 year line span.

Programmers will use their first working solution as a template for every similar project, you can bet the codebase is a massive pile of cut and paste, long past being maintainable.
Hmmm, I'm not going to question your observation (which doesn't match mine), but what had this to do with the subject?
2000 line subroutines require exponentially more time to understand and review than a group of small subroutines, because they require exponentially more time than the 10 to 20 smaller (by 2 orders of magnitude) subs a decent implementation would probably use.
Really? Always? Does 2000 lines of code somehow suddenly always become easier to understand if we scatter the lines into different subs, possible split over different files? Note that I'm not denying that this is often the case - my claim is that sometimes it isn't. If to understand the entire working of a sub means understanding all the pieces, and their order, moving those pieces away doesn't make it easier to understand. In fact, it becomes more annoying - as the linear flow is gone (it's like reading a text where you got to have read the footnotes at the end of the chapter to understand it). And argument passing actually means more code, which sometimes can make it harder.
If 2000 line subs are common where the man works
Beep! Red Herring Alert! Stating that SOMETIMES a thing may happen in no way means such a thing is common.
He should get out before that culture infects him to any great extent.
While we are in the subject of making broad generalizations, I think anyone claiming "never" or "always" isn't fit as a programmer, and should never (;-))have been hired. You claim 2000 line subroutines are always bad - just based on line count? Step away from the keyboard and never touch it again.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://838800]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others browsing the Monastery: (4)
As of 2024-03-29 05:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found