One place I worked at had no coding standards either. The result was code that no one understood or could support. It was fairly common to have 1 subroutine to be 2000 lines! I repeat 2000 lines! What the hell!
Yes, and?
Are you suggesting to solve that with a coding standard that says "No subroutine shall be more than N lines"? What should N be? 1000? 100? 10? 2? Does N include lines that contain nothing but comments? Nothing but white space? Nothing but an opening or closing parenthesis? What if the result of picking an N is that programmers start using nested maps on a single line, instead of multiline nested for loops, just so their subroutines fit in the N line maximum?
I can imagine cases where a single 2000 line subroutine is preferable over splitting it up. There are 10 line subroutines that should be split up in two separate routines.
| [reply] |
Piffle.
That you have to imagine cases where 2000 line subs are preferred, tells me exactly how often such cases really occur: almost never.
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.
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.
The issue isn't one one of arbitrarily counting elements
of syntax, but clarity of expression: at every level, any reasonably experienced reviewer should be able to see what the code is doing and how it fits into the big picture, without having to think about it.
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.
If 2000 line subs are common where the man works, something his company's programming culture is badly
messed up, and nothing short of wholesale replacement
of the entire development staff from the top down will
make things better.
He should get out before that culture infects him to
any great extent.
| [reply] |
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.
| [reply] |
