Chekstyle extensions and modifications and plugins

[Roman Ivanov]

Hi @aunkrig, 

please add yourself to that table first and after that lets discuss how to improve general view of that table.

> By the way, is there a catalog of globally available checks?

there is not such catalog, I only started collecting other checkstyle instances/usages.

> Or is the concept to "embrace" other projects and encourage them to integrate their checks into github checkstyle?

when I started with checkstyle, a lot of Checks were with problems: a lot of false-positives, lack of testing before releasing new Check, inappropriate validation rules (typeaware checks, strikt code duplications..... ), .... . So that make user feel bad about checkstyle as it is buggy.

SO now we remove all useless and non working functionality to let user see that checkstyle become reliable in main set of rules.

read more at - https://groups.google.com/forum/#!topic/checkstyle-devel/JbhfiiSqKsQ

So definitely, other Checks have right to live, and most of the generic enough to be part of main library.

After stabilization period, I will be ready to discuss joining of standalone Checks to main library, for now they should continue to live separately.

But I am interested with join them to main library.

Right now we nave "sevntu" project as collector of such checks, I hope after most of issues are resolved I will start moving them to main library.

> However I feel that there must be a lot of "specific" checks that are totally generic, but still useful for evenly "specific" audiences, an be it only as an inspiration for one's own checks.

yes, I all of them will be welcome to become part of main Checkstyle distribution. Checks that are too specific should have ability to be easily be used even they are not in main library yet.

thanks,

Roman Ivanov

[Arno Unkrig]

On Sunday, December 21, 2014 6:24:07 PM UTC+1, Roman Ivanov wrote:

Hi @aunkrig, 

please add yourself to that table first and after that lets discuss how to improve general view of that table.

Done!

> By the way, is there a catalog of globally available checks?

there is not such catalog, I only started collecting other checkstyle instances/usages.

A comprehensive catalog would be great! BTW, many checks can also be used in non-Java contexts, so a catalog should mention in which environments a check can be useful.
 

> Or is the concept to "embrace" other projects and encourage them to integrate their checks into github checkstyle?

when I started with checkstyle, a lot of Checks were with problems: a lot of false-positives, lack of testing before releasing new Check, inappropriate validation rules (typeaware checks, strikt code duplications..... ), .... . So that make user feel bad about checkstyle as it is buggy.

SO now we remove all useless and non working functionality to let user see that checkstyle become reliable in main set of rules.

read more at - https://groups.google.com/forum/#!topic/checkstyle-devel/JbhfiiSqKsQ

I understand that very well! The more important is the catalog ;-) .

So definitely, other Checks have right to live, and most of the generic enough to be part of main library.

After stabilization period, I will be ready to discuss joining of standalone Checks to main library, for now they should continue to live separately.

But I am interested with join them to main library.

Right now we nave "sevntu" project as collector of such checks, I hope after most of issues are resolved I will start moving them to main library.

Currently FOUR checks live both in SevNTU AND CS with the same names, which givens ECLIPSE-CS a headache.
Two questions here:

• Why do the checks still exist in SevNTU, slightly different?
• Shouldn't CS treat duplicate check names as an error condition?
• Has anybody ever considered to define a concise naming scheme for rules? That makes it both for people and machines easier to pick the "right" check. I decided to name my own checks "de.unkrig.Something"
  

[Roman Ivanov]

Hi Arno,

> Done!

Where ? I  do not see any PR .

> Why do the checks still exist in SevNTU, slightly different?

They should not, As far as I know they are already removed from code, but might be we did not released that yet.

If smth is missed - please feel free to provide PR for removal.

> Shouldn't CS treat duplicate check names as an error condition?

SEVNU-Checkstyle and Checkstyle are different. So Both Check have the same name but different packages so they are two independent Checks. No errors expected.

> Has anybody ever considered to define a concise naming scheme for rules? That makes it both for people and machines easier to pick the "right" check. I decided to name my own checks "de.unkrig.Something"  

I do not understand what you are suggesting - please be expand you idea and make an examples of bad names and good names and .....

thanks,

Roman Ivanov

​