review: refactor(*): Remove redundant supertypes #4369
Conversation
The following has changed in the code: Removed interface java.io.Serializable from type spoon.reflect.cu.position.NoSourcePosition, because it's redundant Removed interface spoon.reflect.declaration.CtTypeMember from type spoon.reflect.declaration.CtConstructor, because it's redundant Removed interface spoon.reflect.declaration.CtTypeMember from type spoon.reflect.declaration.CtMethod, because it's redundant Removed interface java.io.Serializable from type spoon.support.reflect.cu.position.BodyHolderSourcePositionImpl, because it's redundant Removed interface java.io.Serializable from type spoon.support.reflect.cu.position.CompoundSourcePositionImpl, because it's redundant Removed interface java.io.Serializable from type spoon.support.reflect.cu.position.DeclarationSourcePositionImpl, because it's redundant Removed interface java.io.Serializable from type spoon.support.reflect.cu.position.SourcePositionImpl, because it's redundant Removed interface java.io.Serializable from type spoon.support.reflect.declaration.CtElementImpl, because it's redundant Removed interface spoon.reflect.visitor.Filter from type spoon.reflect.visitor.filter.AbstractReferenceFilter, because it's redundant
MartinWitt
force-pushed
the
refactor/automaticQodana/redundantSuperTypes
branch
from
4aee4e4 to
498d8b5
Compare
MartinWitt
changed the title
|
Interesting, thanks @MartinWitt In programming, explicitness is good. Here, the supertypes are explicit, and there is no risk of error because the compiler entirely checks for consistency. So I'm not in favor of this PR because explicitness is good. |
|
I have a hard time in believing the information a programmer editing a class extending |
|
I have to agree with @MartinWitt here. This is both not done consistently, and there's also very little value in redeclaring superinterfaces/implemented interfaces. A modern IDE will quickly tell you all inherited/implemented interfaces, and Javadoc always lists all of them for any given class or interface. See for example NoSourcePosition. So I vote for merging this. |
I disagree on this statement. We make an informed decision based on cost/benefit analysis. If removing or adding everywhere is too costly for too little benefits, it's not good. This is best-effort open source.
then go ahead :) |
|
Here is the link to the related sonar rule for documentation propose https://rules.sonarsource.com/java/RSPEC-1939 |
|
Thanks @MartinWitt |
Removed a lot of not needed supertypes in the code, where other supertypes already have the interface as supertype.
The following has changed in the code:
Removed interface java.io.Serializable from type spoon.reflect.cu.position.NoSourcePosition, because it's redundant
Removed interface spoon.reflect.declaration.CtTypeMember from type spoon.reflect.declaration.CtConstructor, because it's redundant
Removed interface spoon.reflect.declaration.CtTypeMember from type spoon.reflect.declaration.CtMethod, because it's redundant
Removed interface java.io.Serializable from type spoon.support.reflect.cu.position.BodyHolderSourcePositionImpl, because it's redundant
Removed interface java.io.Serializable from type spoon.support.reflect.cu.position.CompoundSourcePositionImpl, because it's redundant
Removed interface java.io.Serializable from type spoon.support.reflect.cu.position.DeclarationSourcePositionImpl, because it's redundant
Removed interface java.io.Serializable from type spoon.support.reflect.cu.position.SourcePositionImpl, because it's redundant
Removed interface java.io.Serializable from type spoon.support.reflect.declaration.CtElementImpl, because it's redundant
Removed interface spoon.reflect.visitor.Filter from type spoon.reflect.visitor.filter.AbstractReferenceFilter, because it's redundant