New submission from Kat katerinab@gmail.com:
I've loaded a model with 32 functions, none of which define any lines of code information. In the Moose window, it shows that the LOC and RLOC properties are both -32. Attached is a copy of the MSE file triggering this.
---------- files: loc.mse messages: 84 nosy: kat priority: Bug status: unread title: LOC off by one error
________________________________________________ Moose Bugs moose-dev@iam.unibe.ch http://macamis.unibe.ch/trackers/moose/issue64 ________________________________________________
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:
New submission from Kat katerinab@gmail.com:
I've loaded a model with 32 functions, none of which define any lines of code information. In the Moose window, it shows that the LOC and RLOC properties are both -32. Attached is a copy of the MSE file triggering this.
files: loc.mse messages: 84 nosy: kat priority: Bug status: unread title: LOC off by one error
Moose Bugs moose-dev@iam.unibe.ch http://macamis.unibe.ch/trackers/moose/issue64 ________________________________________________ <loc.mse> _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- 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."
Hi Doru, please have a look at Meta, each property can have its own default value.
cheers, AA
On 1 May 2007, at 0:50 , Tudor Girba wrote:
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:
New submission from Kat katerinab@gmail.com:
I've loaded a model with 32 functions, none of which define any lines of code information. In the Moose window, it shows that the LOC and RLOC properties are both -32. Attached is a copy of the MSE file triggering this.
files: loc.mse messages: 84 nosy: kat priority: Bug status: unread title: LOC off by one error
Moose Bugs moose-dev@iam.unibe.ch http://macamis.unibe.ch/trackers/moose/issue64 ________________________________________________ <loc.mse> _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- 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@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).
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.
+1
Like the idea of a NullObject for undef values.
A
On 1 May 2007, at 11:59 , Katerina Barone-Adesi wrote:
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).
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.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Adrian Kuhn -
Kat -
Katerina Barone-Adesi -
Tudor Girba