Questions and analyze about jpeek

[0crat]

@yegor256 please, pay attention to this issue

[sergey-karazhenets]

I've created pull request #54 for show a bug with generic methods. Pull request relates only for CAMC metric, but if we are going to fix it I will add test for all metrics. Let's see what was happened in tests for class OverrideGenericMethodFromInterface. Accoding to our current implemented logic we expect in test that CAMC will be calculated as:

l = 2 (two distinct types: int, java.lang.Integer)
k = 2 (methods: construnctor, inc())
a = 1 (type: int) + 1 (type: java.lang.Integer) = 2

CAMC = a / (l * k) = 2 / (2 * 2) = 2 / 4 = 0.5000

But result was 0.3333. It was happend because we counted synthetic methods. See point 4 with a bytecode that copiler produces. According to that bytecode we calculate:

l = 3 (three distinct types: int, java.lang.Integer, java.lang.Object)
k = 3 (methods: construnctor, inc(), synthetic inc())
a = 1 (type: int) + 1 (type: java.lang.Integer) + 1 (type: java.lang.Object) = 3

CAMC = a / (l * k) = 3 / (3 * 3) = 3 / 9 = 0.3333

I will fix that if we will decide that is wrong behaviour or you can just close pull request without merging and without any fixes.

[yegor256]

@sergey-karazhenets for CAMC:

1. So, am I right that we should count only parameter types of method for l?

Yes, totally agree.

2. So, should we consider simple types and theirs analogous boxed types as the same types or consider them as different types (like compiler does)?

I think we should treat Integer and int as one type. I think that we should introduce a new class which will do exactly that -- fetch the list of types from a method signature. And it has to explicitly say in its Javadoc how do we understand the differences between types. This should not be a decision for CAMC metric only, but for the entire product. Make sense?

3. So, is it correct that we consider constructors as methods?

I think we should not consider constructors as methods. Let's try to find some papers that confirm that. Again, let's create a class that will fetch all methods from a class. Let's use it everywhere in all metrics, to make this decision universal for the entire product.

3. Should we consider only public methods or consider all methods (public, private, protected, package-private)? I think we should consider all methods, but what do you think?

I would say we pay attention only to public methods.

I will fix that if we will decide that is wrong behaviour or you can just close pull request without merging and without any fixes.

I agree with the fix introduced.

[yegor256]

@sergey-karazhenets once again, let's not forget that there are many metrics. Let's try to make all changes apply to all metrics. Try to introduce new classes, instead of making changes to specific metrics.

[yegor256]

@sergey-karazhenets can you please split this ticket to a few separate tickets? Now it's difficult to track the progress.