Function Points

[David Bovill]

On 09/05/07, Richard Gaskin <ambassador at fourthworld.com> wrote:

> It started out with an interest in cyclomatic complexity, tailoring
> McCabe's algorithm to be more appropriate for Rev (for example, I weight
> "send...in time" since it's one of the few ways you can introduce race
> conditions into Rev code, and race conditions eat disproportionate time
> when diagnosing bugs).


Looks fun - but I don't get the point yet.... why would you want to quantify
the code complexity - seems overkill for working out how much to pay
freelancers :)

Then I added a few other metrics, including fan-in and fan-out, which
> led to the "Fandango" design pattern Ken and I talked about in our
> session last year at RevCon West.
>
> Fan-in/Fan-out sound like overlaps of your dependency diagrams.  I've
> avoided the challenge of diagramming dependencies myself, as the ROI
> didn't match up for my needs.
>
> But if you have dependency diagramming already in place, there may
> indeed be some way the two tools could be integrated.


Pretty sure that:* M* = *E* − *N* + *2 *where *M* = cyclomatic
complexity*E*= the number of edges of the graph
*N* = the number of nodes of the graph*P* = the number of connected
components.is pretty much there in the code though it would need to be
amended to include intra-hadler node connections, as to date i have only
been interested in graphing handler relationships not overall complexity.

The weak link to such an integration may be on my end:  while useful,
> they're of a lower priority than client work, so they get attention only
> in between phases with more important projects.  As a result, it's hard
> to say when it'll be in any form that others could use.


Ditto - still good to know what you are up to and where to ask questions.