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.
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
