Personally, I like that - and I try to use it as a general rule of thumb.

Cheers,
Darren :)

(Hopefully not showing my age too much, but) I originally heard that n years ago as "more than a single page" when printed, but the sentiment survives. If a sub is spread over more than a single "contextual unit" (printed page, screen full) you start to spend more time trying to track where you are in the big picture rather than following the flow of the logic.

(Of course when you run a 1280x1024 monitor rotated to portrait orientation "a single screen" can get pretty long . . . :)

if any subroutine takes up more than a single screen when viewed in your editor - then it is probably too big

For mine ... if any subroutine takes up more than a single screen when viewed in your editor - then you probably need a different editor, or a bigger screen ;-)

Cheers,
Rob

I've seen useful modules that were really only one line. But, of course, most useful modules are more than that. Some problems demand quite a large module. When part of the module's functionality can be split out into a logically consistent separate module (or even just a separate package), then that is often wise. If you can come up with a good name for this separate piece, then that is a good sign that you've identified a set of features that makes sense to separate (and coming up with a good name is extremely important when factoring out a chunk of features / code).

So about the only time where size is much of a conern for me as related to modules, is when the implementing of a module calls for several small packages and I wonder if it is better to implement all of the packages in one file or split some or all of them into separate files (and there aren't other more important factors motivating that decision -- usually one package per file is best). Or, rarely, as a "red flag" telling me that I did a poor job of factoring the module's too-large functionality or of "reducing scope" to produce a manageable feature set.

So, for modules, I think it is much more about the size and cohesiveness of the feature set than it is about number of lines of code. It doesn't take all that much to have several hundred lines of code in a module so I wouldn't consider 1000 lines of code in a module to be a "red flag".

For subroutines, single-line subroutines are often useful, of course. But here I put a much stronger upper limit on what I consider appropriate size. Subroutines are a basic unit of abstraction so each one needs to be easy to understand as a unit. So I'm very much against overly long subroutines. I prefer subroutines of a couple dozen lines or fewer, so that they fit in a standard terminal window (24x80). In practice, I don't find this metric too difficult to stick to, especially in Perl, but I certainly don't consider it a hard limit. It is easy to justify going over, especially when coding style guidelines demand near-waste of vertical space with unnested opening curly braces, extensive intra-sub comments and vertical whitespace, or (as mine do) don't allow for flow control stuffed into a single line. But I'm very reluctant to leave a subroutine of over about 60 lines.

If I can't view the entire subroutine at once on a larger-than-I-usually-use window or a page of paper, then it detracts from my ability to quickly and clearly understand it. And, of course, having a good name for each subroutine is very important, though many of those names only need to make sense within the context of their surrounding code.

There are, of course, cases where it doesn't seem convenient to split subroutines down to that small of a size. And you don't want to get bogged down obsessing over how to meet some arbitrary size limit, especially since not seeing how to do it often means that if you do it anyway you'll do it poorly. So putting it off can be a wise choice (and procrastination often means not having to do it). My experience is that such difficulties usually stem from missing a good factoring angle or technique. For example, making the code driven by data and having the data expand beyond one screen-/page-full is one technique. I don't mind repetetive data spanning pages nearly as much.

A thoughtful reply. Thank you.

I mentioned already that this is a CGI::Application program -- the subs are run modes, and each of the subs in the modules are run modes related to users, files and projects. There may be some duplicated code, code that I can refactor, but I don't think I'm at that stage yet. The routines are basically ones that collect information from the CGI activity (GET or POST), do some database calls, and display the results using Template::Toolkit.

It seems that I'm not in a Bad Place yet .. so I may well just hold off any drastic changes.

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

My ideal size of a subroutine is "one thought". More specifically, a subroutine ought to be short--easy to understand when separated from the rest of your application. If it gets too large, then usually it's because you have other thoughts in there that should be split out as their own subroutines. Sometimes, however, it's long because the thought isn't naturally decomposable into multiple smaller thoughts. I can't think of an example off-hand, because I find these to be rarities.

...roboticus

A state machine implementation is often done as a "switch" statement (read "if ... elsif ..." in Perl) and can get pretty long even when most of the work for each state is factored out into individual subs. There are ways to avoid the "switch" (dispatch tables for example), but often the operation of the state machine becomes less obvious.

---

DWIM is Perl's answer to Gödel

A state machine is a perfect example of what I was talking about with moving the long stuff to a data structure. Then you have a small dispatching routine and probably a long, repetitive data structure but no long code that you are trying to understand the structure of.

I've worked a lot with state machines. With a non-trivial state machine, you don't look at the code to understand the state machine, you look at the state diagram. And the routines for each state are usually quite small, often tiny.

For more casual state machines, factoring out the per-state actions is often important because otherwise you can't see how the states relate.

So my guidelines for factoring out code from a state machine routine based on size are the same as for other code. And it is usually easier with state machine code because one state makes a perfect chunk to factor out.

- tye        

That's a very good example. When you write & document software, you don't normally use state machines. But when you do, it's because that's the best representation of that piece of the problem. And that state machine is the concept that you need to map to a subroutine, which naturally maps to a larger-than-normal subroutine. (Which thankfully has a simple, repetitive form, as you mention.)

...roboticus

Refactoring only because you think your modules are too long is not a really good practice. One should think about what these modules represent and how easy they will be to fix (enormous modules may mean your subs are very tightly coupled, which is not a good thing). If, however, there is no obvious way to split the module's responsibility — it should stay as a whole despite its size.

1000 lines is rather typical and probably fine, though. Unless they are written in a very terse, domain-specific way, of course — count concepts, not lines.

I have a few modules which are about 1000 lines in length, but these start getting difficult to maintain. Most of my modules are less than 500 lines.

I'm wondering how much repeated code you have in your 3 modules - with a bit of refactoring, you could probably split those modules up, and make more of code reuse. Besides being easier to follow, they'll make maintenance less of a nightmare.

Clint

Well I hate to get all academic-y but I'm a big fan of using complexity metrics for measuring subroutines/methods/functions. The higher the complexity metric (ie, more conditionals) - the harder it is to test and that's a good reason to refactor a subroutine. As for modules ... well just like the maxim says, take care of your subroutines and your modules will take care of themselves.

Update: CPAN continues to amaze me.

• I'm often working with fairly simple concepts.
• I let CPAN modules do much of the heavy lifting when I can.
• I use mostly OO these days.I, personally, would rather have more simple objects than fewer complex ones -- as simple as makes sense, but no simpler. I usually break my modules along class lines.
• I've found I can reuse modules easier the less they do. That means I'll write a module meant for reuse and another that either wraps or subclasses it for just the initial project if I think most of the module will be useful elsewhere but want to keep a bunch of extra stuff out of it.
• Modularity can save space when reusing code if you don't need everything from one project in another, too.

• recognize a pattern from this set, grab the pertinent data, and perform a corresponding action from another set
• perform a sequence of actions based on a sequence of tokens (little languages)
• parse a pattern and perform actions based on the state of the system (state machines)
• etc., etc., etc.

• create a sub where you use the same code more than once (that means twice!, or more)
• generalize subs via parameters to avoid having multiple similar subs
• if you have a long (ie >500 line) sequence of "meat & potatoes" code, then it is a good idea to reduce your "main" routine to a 30 line-ish sequence of calls to subs ... this is really a way to self document the code and forces you to limit use of global variables to make the code more re-usable