I can try it next week. My new job has me with lots of spare time on
my hands. (Had to get a contractor in right away, but didn't resolve
the politics of what that contractor was going to do when he got
there. *shrugs* Their dime.)
Rob
On Mon Nov 22 12:56:16 PST 2004, <> wrote:
> [EMAIL PROTECTED]>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
> Message-Id: <[EMAIL PROTECTED]>
> Content-Transfer-Encoding: 7bit
> From: Stevan Little <[EMAIL PROTECTED]>
> Subject: Re: [sw-design] (no subject)
> Date: Mon, 22 Nov 2004 15:54:14 -0500
>
>
> To: practical discussion of Perl software design <[EMAIL PROTECTED]>
> X-Mailer: Apple Mail (2.619)
>
> Rob,
>
> On Nov 22, 2004, at 1:23 PM, Rob Kinyon wrote:
> >> I agree, opcodes will have optimizations in them which will affect the
> >> count so they can be flawed there. And also things like assignment
> >> statements which are one line of perl code are a lot more opcodes that
> >> one might initially think. ...
> >
> > It's not a matter of optimization like -O2 or whatever. It's a matter
> > of optimizing the written code for maintainability. A better example
> > would be a loop vs. unrolling that loop. A standard for-loop would be,
> > say, one decision point plus 5 statements. Unrolled, that loop may be
> > 5 statements * 100 items for 500 statements. Which one is easier to
> > maintain? Optimizing for maintainability is, imho, much more
> > important, in general, than optimizing for opcode efficiency.
>
> Okay, I see your point here. I still like my opcodes through, *grumble*
> *grumble* .... :-P
>
>
>
> >
> >> ... I like your idea of measuring the decision points, and in
> >> particular their density. And Matt had a good suggestion with tokens
> >> too.
> >
> > Unfortunately, it's not my idea. It's one of the more recent crazes in
> > software analysis. Of course, I can't remember the name of the theory,
> > but it's out there. Google for "software decision point" and you'll
> > hit a bunch of articles.
> >
> > Personally, I think that we should be looking at minimizing the number
> > of tokens in a block, as that increases readability of that block.
> > (The less to read, the easier to read it all.) This would imply that
> > creating a set of one-use functions for a complex set of operations is
> > a good thing.
>
> I think at some point too few tokens becomes an
> readability/understandability issue as well. There will have to be a
> balance as well since perl has so many shortcuts you can take. For
> instance there is a difference in the number of tokens between code
> written without strict and code written with strict.
>
> I would also argue that code like this:
>
> foreach my $value (@values) {
> print "$value\n";
> }
>
> is more readable and maintainable in the long run than this:
>
> $\ = "\n";
> print foreach @values;
>
> And this brings up the point as well of how do we treat statement
> modifiers? As a block?
>
> Some of this really comes down to style issues I think. One would have
> to be careful not to write in to many of their own stylistic choices
> into such an analyzer.
>
> >
> > Additionally, minimizing the number of tokens in a block also implies
> > keeping functions to a minimal size, which maps well to most people's
> > feelings that functions should be no more than 50 lines long,
> > including comments.
>
> This comes back to the LOC thing too.
>
>
>
> >
> > Decision point minimizing ... that's a tough one. There is a minimum
> > number of decision points that any given problem must have in order to
> > correctly model that problem's complexity. If you dip below that
> > number, you have incorrectly modeled the problem. Going over that
> > number means you have (potentially) modeled the problem correctly, but
> > with additional complexity. That said, we can probably come up with a
> > useful metric regarding the number of decision points within a given
> > block.
>
> I think maybe (in most conditions) the number of decision points will
> relate to the number of LOC/tokens in the blocks. For instance, if my
> if/elsif/else blocks have a large amount of tokens in them, chances are
> this is a good canidate for refactoring into subroutines. If I have a
> lot of decision points with very little code in them, chances are this
> is a good canidate for refactoring utilizing either polymorphism or a
> dispatch table of some kind.
>
> With a little creative use of heuristics I think we could do this. I
> mean in the end, nothing this would say would be any more than just
> suggestions. Personally I would like to use something like this for
> large scale code anaylsis, where I could keep a handle upon the growth
> of a project over time. Being able to see it from such a high level
> statistical POV would help me track where things are maybe starting to
> slide/go wrong and catch it before it gets bad.
>
>
>
> >
> > *looks over what he has been babbling*
> >
> > It seems to me that the block is rapidly becoming, at least for me,
> > the actual unit we want to measure stuff about. In Perl (and other
> > C-derived languages), the block is very neatly delimited by { ... }.
> > Coincedentally, that comes back to the line-folding idea that Matt
> > intially brought up as a starting point for analysis.
> >
> > So, maybe we should look at block and count the following:
> > 1) Number of tokens
> > 2) Number of decision points
> > 3) Number of child-blocks
> > 4) Number of function calls (core and otherwise)
>
> I think this is a good start. I think we could try using the PPI
> module's tokenizer (which is supposed to be pretty good). Anyone out
> there want try to taking this on?
>
> Steve
>
>
>
>
> > The reason for function calls is that they require additional
> > knowledge that isn't specified within the block itself. It's an
> > increaser of global complexity (more outside knowledge needed) and a
> > decreaser of local complexity (less stuff happening in this block).
> > It's not immediately clear exactly how we would want to weight #4.
> >
> > Rob
> >
> > _______________________________________________
> > 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
