Hello!
I’m not the gatekeeper for new releases to the Marketplace here, but I took a glance at your plugin and… I have some feedback. 
You mention that a complete list of rules are described in the README, which is… accurate. And looking at the list of rules, none of them are particularly clear to me.
-
What is a “lazy” class? How do I avoid writing one so that I don’t trigger an issue? Same question for “Shotgun Surgery” and “Refused Bequest”?
-
Lots of your rules use the word “large” and “long”. How do you define “large” or “long” for each rule?
I thought there might be some more clarity once I actually installed the plugin and checked out rule descriptions. Unfortunately not.
Descriptions should answer questions “why is there an issue?”, “what could be its impact?”. Compliant / Non-compliant code examples are also missing for all rules. If there are really TO DO items, maybe they should be done before your first release!
I executed analysis against a sample project (an old copy of sonar-php I had around) and while analysis ultimately succeeded, I got a huge number of errors like this:
[ **ERROR** ] Unable to run check class org.codehawk.plugin.java.checks.RefusedBequest - refused bequest on file 'php-checks/src/main/java/org/sonar/php/checks/utils/type/NewObjectCall.java', To help improve SonarJava, please report this problem to SonarSource : see https://www.sonarqube.org/community/
java.lang.NullPointerException: null
at org.codehawk.plugin.java.checks.RefusedBequest.visitNode(RefusedBequest.java:100)
at org.sonar.java.model.VisitorsBridge$IssuableSubsciptionVisitorsRunner.lambda$visit$6(VisitorsBridge.java:307)
at org.sonar.java.model.VisitorsBridge$IssuableSubsciptionVisitorsRunner.lambda$forEach$9(VisitorsBridge.java:322)
at org.sonar.java.model.VisitorsBridge.runScanner(VisitorsBridge.java:173)
at org.sonar.java.model.VisitorsBridge.access$100(VisitorsBridge.java:68)
at org.sonar.java.model.VisitorsBridge$IssuableSubsciptionVisitorsRunner.forEach(VisitorsBridge.java:322)
at org.sonar.java.model.VisitorsBridge$IssuableSubsciptionVisitorsRunner.visit(VisitorsBridge.java:309)
at org.sonar.java.model.VisitorsBridge$IssuableSubsciptionVisitorsRunner.visitChildren(VisitorsBridge.java:293)
at org.sonar.java.model.VisitorsBridge$IssuableSubsciptionVisitorsRunner.visit(VisitorsBridge.java:313)
at org.sonar.java.model.VisitorsBridge$IssuableSubsciptionVisitorsRunner.run(VisitorsBridge.java:284)
at org.sonar.java.model.VisitorsBridge.visitFile(VisitorsBridge.java:155)
at org.sonar.java.ast.JavaAstScanner.simpleScan(JavaAstScanner.java:99)
at org.sonar.java.ast.JavaAstScanner.scan(JavaAstScanner.java:65)
at org.sonar.java.JavaSquid.scanSources(JavaSquid.java:111)
at org.sonar.java.JavaSquid.scan(JavaSquid.java:105)
at org.sonar.plugins.java.JavaSquidSensor.execute(JavaSquidSensor.java:88)
Not sure if it matters, but this was on a SonarQube v7.9.2 instance with SonarJava v6.0 installed!
For the issues that were raised, there were some formatting issues in the issue titles.
Finally, there’s overlap between the rules in your plugin and rules already provided by SonarQube’s Java analysis. Some examples:
RSPEC-107: Methods should not have too many parameters
RSPEC-1479: “switch” statements should not have too many “case” clauses
RSPEC-138: Methods should not have too many lines
What do your implementation of the rules bring to the table, so that a user should disable existing rules and add the rules from your plugin?
While maybe an interesting exercise with the SonarJava API (and seriously, kudos on the work you’ve done, rule development is tough!) it might be good to step back and ask yourself if your plugin is really ready for the Marketplace with this release.
Best regards,
Colin
)
)