Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • I can see where you're going with this, Ovid. Can Test::Smell be far behind (um, pun not intended)?

    I can see it testing all of the classes in your project and emitting passes or failures for inheritance patterns, hidden method, long method bodies, etc.

    • I'm not so sure a code smell should be a test failure. Perhaps Perl::Critic is where Ovid's sniff logic would be put to best use?

      • This is like Critic, but I'm using running code, not document analysis. Therefore, I can do something things which Perl::Critic cannot (just as it can do some things which I cannot). For example, it's very, very hard to get a good inheritance tree from Critic. There are a number of obscure ways of setting up inheritance (see DBIx::Class and Catalyst as examples) which PPI wouldn't find terribly well.

    • Wow. I hadn't thought of that. Personally, I'd prefer someone else write that. These are good rules of thumb, but they don't satisfy the binary nature of tests :)

  • I've seen plenty of claims that long methods are a code smell. I've repeated such claims myself. But are you aware of any actual data demonstrating that short methods are better? I am not, and in fact the highly limited data that I am aware of says the exact opposite.

    For what it is worth, the last time I tried to get my thoughts down on this subject was several years ago in Short routines matter more in OO? [] and I have not read anything new on the topic since. So I still have the cognitive dissonance of

    • As I've said before, it's a code smell, not a code error. If your method is 100 lines long but it's doing one, cohesive thing, maybe it's not an error. Maybe trying to abstract everything into methods from that would hurt readability. Maybe it does three things but you're happy with that. Your mileage may vary.

      If you don't like the heuristic, set your threshold to 5000 or something and don't worry about it. I'm just trying to provide a tool and I expect people to evaluate its utility for themselves. Y

      • I think you miss my point. It is not that I want to have long subroutines. It is that I prefer short subroutines, but am concerned that the concrete data I have says that I really should be using longer ones.

        So which is right? My gut sense? Or the data?

        • After doing a bit more reading on this (reading Code Complete's section, for example), it does sound like you're right and perhaps this is something wrong to put in here. This, coupled with some implementation issues, may lead me to pull this.

          Thanks for raising this issue.