Reviving this thread a bit - a quick summary of where things were left: 1. no one seems specifically against adding a tool of this kind (though Florian went so far as to be positive on doing so) 2. if we did add a tool it was a good suggestion to get the tool selected first and then slowly enable different checks. 3. having multi-language support in the tool was brought up as a possible requirement in tool selection
the more i've thought about it the more that I think my preference for putting code analysis in place would involve using a tool that provided multi-language support. Therefore, something like sonarqube or coverity would be more appealing to me than the original JVM only solution that was proposed. Is that basically the representative feeling on this for everyone? On Wed, Mar 21, 2018 at 10:03 AM, Robert Dale <robd...@gmail.com> wrote: > It has multi-language support - > https://community.synopsys.com/s/question/0D53400003WcsSiCAJ/what- > languages-are-supported-by-synopsys-static-analysis-coverity > > Robert Dale > > On Wed, Mar 21, 2018 at 10:01 AM, Robert Dale <robd...@gmail.com> wrote: > > > Another option might be to use Coverity - https://scan.coverity.com/faq > - > > and run it in Travis CI > > > > Robert Dale > > > > On Wed, Mar 21, 2018 at 9:43 AM, Stephen Mallette <spmalle...@gmail.com> > > wrote: > > > >> > I think any proposed changes would be separate PRs and reviewed on a > >> case-by-case > >> basis. > >> > >> yeah - i think if we want something like this the goal should first be > to > >> decide on a tool (i can't say that i agree with Roman that "running more > >> tools is always better" btw). note i'm still saying, "if we want > something > >> like this" because while i'm not against it I'd like to be convinced > that > >> we need to worry about this now at this stage of TinkerPop's > development. > >> i'd have been more inclined to deal with this early on in TinkerPop's > >> development rather than now. And, yes, also agree that i would like to > see > >> the tool in first and then each introduction of "rule" be a separate > >> discussion and PR. > >> > >> > As for making it the default compiler, I think this would be a > profile, > >> disabled by default, at best at least until a time it can be massaged to > >> where it works for this project. > >> > >> yeah....that might be a smart way to go > >> > >> > whether other static analysis tools would find most of the problems > >> that > >> such a compiler can find and also work with other languages than Java. > >> > >> very good thought. while the bulk of our code is java, we are far from a > >> single language code base. if there is one tool that can give us some > nice > >> clean analysis across the entire code base, perhaps that's the best way > to > >> go (again, "if we want something like this"). > >> > >> > >> > >> > >> On Tue, Mar 20, 2018 at 8:41 AM, Florian Hockmann < > f...@florian-hockmann.de > >> > > >> wrote: > >> > >> > In general, I am +1 on adding a static analysis tool to our tool > chain. > >> > I just wonder whether a Java compiler is the best choice for us right > >> > now or whether other static analysis tools would find most of the > >> > problems that such a compiler can find and also work with other > >> > languages than Java. SonarQube[1] for example looks pretty nice. It > also > >> > supports Python, C#, and JavaScript and we can probably just integrate > >> > it via GitHub to generate reports for the release branches and all PRs > >> > where it would then add issues in the form of inline comments. > >> > > >> > [1] https://www.sonarqube.org/ > >> > > >> > Am 20.03.2018 um 03:42 schrieb Robert Dale: > >> > > Some changes look good others look wrong evident by the failed > >> builds. I > >> > > think any proposed changes would be separate PRs and reviewed on a > >> > > case-by-case basis. As for making it the default compiler, I think > >> this > >> > > would be a profile, disabled by default, at best at least until a > >> time it > >> > > can be massaged to where it works for this project. > >> > > > >> > > On Mon, Mar 19, 2018 at 14:59 Roman Leventov <leventov...@gmail.com > > > >> > wrote: > >> > > > >> > >> See https://github.com/apache/tinkerpop/pull/819. > >> > >> > >> > >> 1) Are there any objections to using error-prone compiler instead > of > >> > >> OpenJDK's javac compiler? > >> > >> 2) Stephen raised the question, that Tinkerpop project may better > use > >> > >> another static analysis tool instead of error-prone. I have to > answer > >> > that > >> > >> no static analysis tool covers 100% of the errors found by any > other > >> > tool, > >> > >> so running more tools is always better. > >> > >> 3) Stephen raised the question, what checks should be enabled. I > >> believe > >> > >> this is out of scope of the PR ( > >> > >> https://github.com/apache/tinkerpop/pull/819), > >> > >> because it doesn't (and doesn't intent to) enable any more checks > >> > beyond > >> > >> the default (= minimal) set of error patterns. More checks may or > may > >> > not > >> > >> be enabled in later PRs and that could be discussed separately. > >> > >> > >> > > >> > > >> > > >> > > > > >
