On 09/05/07, Richard Gaskin <[EMAIL PROTECTED]> 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. _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
