Re: Working with old code

[Tux]

I don't get what people dislike about a 100+ line method/function/subroutine if it has no reason to be split and it the chuncks in the sub have been well separated and commented. There are ereasons enough to keep something that is only ever run as one process to keep together. If none of the parts is reused or used by others there is no reason whatsoever to break it apart, which only *complicates* readability.

Most people that I met that want to break up long sub's seem to come fro a java-enviroment where people are tought that long subs are bad and that even quality checks mark these methods as "bad" as they are too long or too complicated. BULLOCKS!

I 100% agree with the other comments. Start with tests and documentation.

If a found bug needs a fic that would warrant a break-up, only then consider to break up in smaller pieces. Really smaller subs are by no means always better to maintain.

[haj]

I don't get what people dislike about a 100+ line method/function/subroutine if it has no reason to be split and it the chuncks in the sub have been well separated and commented.

I agree that long subroutines aren't necessarily evil. It depends on the case: You have listed some conditions... which quite often aren't met in old code. Subroutines grow, because, let's just add a small feature here, because of why not, only one source file to be changed, and then there's another edge case to be covered, let's just copy that check from the other file where it works just fine. So in my experience long subroutines are often due to "maintenance with small commits", so to minimize the effort for code/patch review, and not because the subroutines were designed that way.

BTW: My most recent bugfix was in a 1120-line sub, mostly written in the previous century, and guess what: Now it has 1123 lines. And I'm not going to split it anytime soon.

[Your Mother]

I’m on your side, I just want to say I think “one screen” of code for a sub is a decent rule of thumb that catches a lot of problems; especially for coders like me who often write code like prose without always having a plan. It’s the point where I ask “Is this the best way to do this?” but not “Oh, no! Better cut this into parts quick.”

I would also rather have a LONG sub than 5 private classes, not an exaggeration in my (well, our) code base, or whatever a Java-oriented hacker might use instead. One of the Perl hackers in my group—designed and wrote most of the early code—was Java-oriented and it’s ostensibly “better engineering” but in practice close to zero-reusuability, widely-denormalized because of it, painful, and confusing code.