Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • You could just make it configurable and give it a decent default. This particular piece of functionality seems like it could be good for Perl::Critic as well.
    • My only concern is that it turns out to be misleading. I don't want to be seen promoting shorter methods if it turns out they're not actually a good idea. Still, if I can make it work more reliably, I will try that. If I can't make it work reliably, then it's a moot point :)

      • Well if you encounter a very long method, it's probably not bad in general, it's probably bad for specific reasons, like:

        It's doing more than one thing, and the things are probably unrelated (which also makes it more difficult to name properly).

        Even if they're not unrelated, it's a missed opportunity to write self documenting code by giving the functionality a (method) name. There are probably documenting comments in there to demarcate the functionality anyway. If not, there should be. Well, unless the method was split up.

        The scope in a long method is probably unecessarily large, making it more difficult to understand, grasp the consequences of, and refactor.

        These are all things that are likely to be true for very long methods.

        • I agree with all of this and it's the reason I included this code smell. That being said, the research seems to indicate otherwise. The subjective experience of many programmers seems to be contradicted by the objective experience of quite a few studies on the subject. See Code Complete 2 for a full list.