Hi, Here are some rules :
Following String methods where left hand side is empty. String.replace() String.toUpperCase() String.toLowerCase() String.replaceFirst() String.trim() In test cases (subblasses of SolrTestCaseJ4) methods without assertU(). see : SOLR-5685 adoc() optimize() commit() String.toUpperCase() and String.toLowerCase() without Locale. see : SOLR-2281 and LUCENE-2466 Can ant precommit/forbidden-apis be used to detect above? Ahmet On Sunday, March 16, 2014 9:53 PM, Benson Margulies <bimargul...@gmail.com> wrote: Just because some tool expresses distaste, doesn't imply that everyone here agrees that it's a problem we should fix. In my experience, the default Sonar rulesets contain many things that people here are prone to disagree with. Start with serialVersionUID: do we care? Why would we care? In what cases to we really believe that a sane person would be using Java serialization with a Lucene/Solr class? Sonar can also be a bit cranky; it arranges for various tools to run via mechanisms that sometimes conflict with the ways you might run them yourself. So I'd suggest a process like: 1. Someone proposes a set of (e.g.) checkstyle rules to live by. 2. That ruleset is refined by experiment. 3. We make violations fail the build. Then lather, rinse, repeat for other tools. Once we have rulesets we agree are worth enforcing, we can look to Sonar for a pretty way to visualize their results if we like. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
