Why not take code-folding-on-indents (which I have just discovered in
gvim, having never used it before) and do something on our own.
Discovering the level of a line of code is as simple as <code>my
$level = $line =~ /($indent)/g;</code> where $indent, for me, would be
\s{4}, but for others might be \t or \s{8} or whatever. (Well, that
would need to be improved a bit, I expect ... maybe
/(?:^|(?<$indent))($indent)/g or something?)As for using code/block size as a metric ... automating it can discover pathological areas, but it cannot prove that a piece of code has good metrics. All you can prove is that it doesn't have bad metrics. It's like testing - you cannot prove a lack of bugs through testing. All you can prove is that, given a whole bunch of assumptions, it probably doesn't have *this* bug or *that* bug. 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? 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
