Could somebody explain how adding a multi-language tool makes adding a single-language tool undesirable, given one doesn't strictly cover another?
On Tue, 3 Apr 2018, 16:36 Stephen Mallette, <spmalle...@gmail.com> wrote: > 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. > > >> > >> > > >> > > > >> > > > >> > > > >> > > > > > > > > >
