Rob,
Fair enough. :-)
Some thoughts (in no particular order): 1) Look at statements, not LOC. Otherwise, you start unfairly penalizing people who uncuddle their elses.
I was really thinking opcodes would be a good way to measure the "size of code", since they are really the final stage before execution. My perl internals knowledge is a little rusty (and it was only "little" to begin with), but I would think using the B modules this type of analysis would not actually be all that hard. Especially since we are only counting them and not really analyzing them.
2) Look at number of decision points. if-blocks, for-loops, while-loops ... things like that. The more of those, the harder it is to follow.
This is a cool idea too. Again, this might work nicely with the opcode tree climbing stuff I am thinking about.
3) If you want this to be truly useful, look for repeated code. I'm not sure how you'd do this - maybe do a String::Approx or Levenstein comparison for any two consecutive statements. The more points of similarity, the more likely it is a refactoring is needed.
Hmm. I would suspect again that we might be able to find this in the opcodes. Although slight variances in code might produce very different opcode sequences. However, I think that the detection of slight differences but the same code, was one of the things that PPI (http://search.cpan.org/~adamk/PPI/) was supposed to do.
4) Looking for time-to-live for variables can also be useful. Something like:
* Lines between declaration and first use
* Lines between last use and end of scope
* Number of uses vs. length/uniqueness of name
Wow, this could get messy to try and parse. But at the risk of sounding like a parrot, maybe it would be simple on the opcode level :)
I dunno. More later, I think.
I dunno either :)
But this has the potential for an interesting module in it I think.
Steve
Rob
On Fri, 19 Nov 2004 23:54:21 -0500, Stevan Little <[EMAIL PROTECTED]> wrote:Rob,
I'm coming into the middle of this conversation ... what's the goal behind these metrics? Either you write good code, in which case you follow the metrics, or you write bad code, in which case you don't care about the metrics. What am I missing?
No goal in particular, just a side thought probably brought on by excessive use of caffine and lack of sleep over the past 7+ years (the age of my oldest daughter).
I agree with your statement about writing good code or writing bad
code. That is true. However, automated tools to help keep you writing
that good code are nice things IMO. For instance Devel::Cover allows me
to know how much of my code is being exercised by my tests. This wont
keep me from writing bad tests (which may still have good coverage
too). But it will help me to see where my tests can improve and what
they might be missing and even sometimes to spot code which can never
be reached.
I guess the idea with this tool would be to help you spot (within a large body of code) places/functions/subroutines which have grown in size and might be in need of refactoring. Its kinda more a suggestive thing, then a definitive 'your code is broken here' thing.
Just an idea, call me crazy (many people do).
:)
Steve
Rob
On Fri, 19 Nov 2004 18:18:58 -0800, Matt Olson <[EMAIL PROTECTED]> wrote:On Thu, 18 Nov 2004 14:55:04 -0500, Stevan Little <[EMAIL PROTECTED]> wrote:Incidentally, 'ensure'- and 'sanity'-block size looks like it might
be
a useful metric for figuring out whether a particular subroutine is
too complex. If you don't want to fill out that 'ensure' block
because you know it's going to be a beast, maybe you're trying to do
too much in one place.
This is actually an excellent idea for just a code metrics tool in general. Something which would loop through your packages and count the code size for each subroutine.
Code-folding in vim (a feature that I Cannot Live Without(tm)) does that for me; I have vim fold on indent level, so it's pretty easy to just close all the folds, flip through the file, and check for any fold that says it's longer than n lines (where n varies depending on the language and the programmer's sobriety). I wonder how you'd automate that... going through with a screen-scraper would really suck.
While we're at it, if you're using code size as a metric, you should probably apply it to blocks, not just to subs. Blocks inside functions should be fairly small, with obvious exceptions for constructors and such. On the other hand, long blocks might be excusable if they consist of many smaller blocks, all relatively compact. The idea is that each level of scope acts sort of as a conceptual bucket: if you only have to deal with a few items at any given scope, you might not care that those items contain hundreds of lines. (Obviously, this is a metric that can be horribly abused.) Does that sound useful?
--Matt
_______________________________________________ sw-design mailing list [EMAIL PROTECTED] http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
_______________________________________________
sw-design mailing list [EMAIL PROTECTED] http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
_______________________________________________ sw-design mailing list [EMAIL PROTECTED] http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
