Hi Kat, The error is because the default value for a metric is -1. Both LOC and RLOC for a namespace accumulates the LOCs of the functions in the namespace. Originally, the default value was 0, but then this value actually has a meaning. Hence, we decided to make the default error value -1, given that measurements are typically > 0. In this light, this is not really a bug. But, I would like to hear opinions of how you think this situation can be improved. Cheers, Doru On Apr 30, 2007, at 2:38 PM, Kat wrote: -- Tudor Girba www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/ "Problem solving should be concentrated on describing the problem in a way that is relevant for the solution." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

I wondered if the rationale was something like "0 is valid, and -1 isn't". However, I think this is bogus - no lines of code information shouldn't be considered negative lines of code. (In the craziest case, take a model where you only have line of code information for some parts... the parts where you don't would then bring down the loc for the whole system). I think 0 is an ok default (as you said, measurements are usually > 0), though imperfect, but better yet would be to have some kind of non-numeric default, which would indicate that the information wasn't available, so you could avoid using it in calculations where it would skew the results - ie, average loc/method (the downside being that this is a bit more awkward to handle). _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev