Remove StrictDuplicateCodeCheck and whole package

[romani]

remove whole com.puppycrawl.tools.checkstyle.checks.duplicates package from Checkstyle.

Reason:
searching duplicate code by strict code comparison is the most error prone approach in static code analysis, as created dependency between classes (caused by following Chckstyle instructions) is more problematic that code duplication. Another reason is that identical code does not mean that it describe the same and could be shared.

[romani]

will be released in 6.2.

[lkoe]

Personally I think that's a really rash decision, with some debatable reasoning attached.

If I understand correctly, you prefer verbatim copy&paste of code over proper code design and reuse of common functionality by delegation.
StrictDuplicateCodeCheck was a simple but efficient tool to discover such verbatim duplications, which are indeed dangerous (duplicated bugs, unawareness of duplication when extending original functionality etc. these arguments and more are well established for decades).

Of course there might be a low proportion of code duplications which may be legitimate (or even "false" positives) - but those can be easily handled by using suppression facilities of Checkstyle.

Another factor in making such decisions should also be the established user and configuration base of Checkstyle. Every time a check (and even one that is not particularly broken) is removed, thousands of Checkstyle configurations out there will be broken when updating, alienating users and stripping them of well established functionality - for in my opinion questionable reasoning.

Therefore I vote for re-adding this well established and useful check.

[romani]

Personally I think that's a really rash decision, with some debatable reasoning attached.

I keep that thought for one year, and persuaded myself to make that breaking compatibility after java8 support is introduced, after that I did few more releases ….. so that is last time I could wait to remove buggy stuff from Checkstyle.

If I understand correctly, you prefer verbatim copy&paste of code over proper code design and reuse of common functionality by delegation.
StrictDuplicateCodeCheck was a simple but efficient tool to discover such verbatim duplications, which are indeed dangerous (duplicated bugs, unawareness of duplication when extending original functionality etc. these arguments and more are well established for decades).

implementation is simple, that is why it is full of bugs and false positives. It is not efficient !!!! It is useless generator of violations. Nobody use that Check as to work with it is too hard. If smb do use it - he should stop live in illusion and look around for better alternatives.

Of course there might be a low proportion of code duplications which may be legitimate (or even "false" positives) - but those can be easily handled by using suppression facilities of Checkstyle.

Suppression is Chekcstyle is not a simple option, even I have problems sometime to suppress violations ( but this is a different update for Checkstyle and plugins to ease that).

Another factor in making such decisions should also be the established user and configuration base of Checkstyle. Every time a check (and even one that is not particularly broken) is removed, thousands of Checkstyle configurations out there will be broken when updating, alienating users and stripping them of well established functionality - for in my opinion questionable reasoning.

That Check produce so much noise that I doubt that anybody use it. And even they use it - they need consider to use smth else. They need to use CPD of PMD for that it works much better and far from simple. But even it far from usable. By means on “usable“ I mean not be crazy with configurations. All attempts to show similar code in non static methods - is false positive in 90%, all further attempts to make system without code duplication is wrong way in design as it introduce dependencies that are much harder to fix rather than code duplication.
Checkstyle will NOT be a container of immature and buggy validations, it was such tool for long time, but not any more. All experiments will be removed from Checkstyle. You might be noticed that the same was happen with “TypeAware” Checks.

Therefore I vote for re-adding this well established and useful check.

thanks for your vote, if I found that smb else(about a bunch of people) is desperately miss that check, I agree to move it to our experimental project - sevntu.checkstyle. But there is no reason to keep in stable Checkstyle.

[netmikey]

We actually are using it (or should I say were?) and quite happy with it. I have to agree with @lkoe - guess why I landed here? ;) A simple Eclipse update spawned errors in the checkstyle builder, which had been updated to 6.2.

I'll have to go through all our project checkstyle configurations and remove that now... It's one thing to deprecate a feature and remove it from default configuration templates, but it's another to break things like this - even with the best intentions.

[romani]

@netmikey, if you need StrictDuplicateCodeCheck so much please move it to sevntu-checkstyle project, our official sandbox project (https://github.com/sevntu-checkstyle/sevntu.checkstyle).

but it's another to break things like this - even with the best intentions.

Bracking things is not good , but that is the only way for Checkstyle to survive as quality of Checkstyle's code is very poor and I will fix the Check if that possible. If Chck idea is incomplete - Check should go to trash or experimental project like sevntu-checkstyle to get maturity.

Right now I expect small bracking compatibility in each release for the next year (I plan to have release at the end of each month). Sorry, that is a payment for several years of lacking time to think and throughly test Checks before introducing them.

[ewoks]

Did u plan some replacement? Some more efficient error and false positive prone solution? In my project CheckStyle was marking crazy stuff as duplicate, code that doesn't have to do with each other at all so i am happy bad implementation is gone, but i would like to have some better solution inside CheckStyle. Thanks

[romani]

no replacements is planned as I have only some ideas how to make code duplication non error prone.
I you have some or you have time to do implementation - you are welcome.

I really recommend to not focus that much on code duplication and focus on minimizing dependencies between code, look at Data Structure Matrix report against Chekstyle - http://checkstyle.sourceforge.net/dsm/index.html it shows design problems . By following guidelines from duplicate code detector - you force your application to introduce dependencies that will not do any good to your code.