Hello. Le dim. 2 juin 2019 à 10:00, Karl Heinz Marbaise <khmarba...@gmx.de> a écrit : > > Hi, > > On 02.06.19 00:06, Alex Herbert wrote: > > > >> On 1 Jun 2019, at 22:49, Gilles Sadowski <gillese...@gmail.com> wrote: > >> > >> Hello. > >> > >> Le sam. 1 juin 2019 à 21:56, Karl Heinz Marbaise <khmarba...@gmx.de> a > >> écrit : > >>> > >>> Hi, > >>> I've created a branch[1] which fixes some checkstyle reported issues. > >>> The resulting build[2] shows the issues have been fixed. > >>> > >>> Can someone take a look at that... > >>> > >>> If there are no objections would it be Ok to merge that to master? > >> > >> I'm against "throws" clauses for unchecked exception; as per J. Bloch: > >> "[...] do not provide throws clauses for unchecked exceptions".[1] > > > I recently upgraded checkstyle in [rng] and [statistics] because it was > > using old configuration that did not utilise recent checkstyle features to > > enforce the coding style. Geometry was based on the same checkstyle and it > > should really be upgraded. > > > > However I did not upgrade [geometry] or [numbers] as a quick check showed > > there were a lot of problems [1] (and I did not have time). Even just > > upgrading checkstyle to 8.20 and keeping the same config finds additional > > problems as the checking is better. > > > > Would you consider incorporating an update to checkstyle in this branch or > > another PR? Most of the work is trivial and should not take long. The main > > source of problems are the tests which could be ignored during checks. > > I think it makes sense to make separate JIRA + Branch and upgrade the > configuration as in statistics...first (also in geometry would make sense). > > afterwards I can reconsider GEOMETRY-54 ... > > I would not ignore tests cause tests should check production code so it > should have the same quality as the production code if not even better
Ideally yes, but their main purpose is to help ensure correctness of the main code, in the same way that CheckStyle helps too, by making the code more readable through consistency. So, enforcing CheckStyle on the test code is a lower priority (wrt, say, getting to a releasable state for the main code...). We could perhaps have a maven profile that selects whether the tests should be scanned or not. And open a general JIRA issue for the task for gradually upgrading all the test sources. You are of course welcome to tackle that task. :-) Please note that it would also mean porting the tests to Junit 5 (as per another recent thread on this list). Regards, Gilles > > Kind regards > Karl Heinz Marbaise > > > > > Alex > > > > > > [1] > > http://mail-archives.apache.org/mod_mbox/commons-dev/201905.mbox/%3C43eb34dc-ebdc-e0d8-c943-a35bc642d4ca%40gmail.com%3E > > > > <http://mail-archives.apache.org/mod_mbox/commons-dev/201905.mbox/%3c43eb34dc-ebdc-e0d8-c943-a35bc642d...@gmail.com%3E> > > > >> > >> Regards, > >> Gilles > >> > >> [1] > >> https://books.google.be/books?id=ka2VUBqHiWkC&pg=PA253&lpg=PA253&dq=effective+java+bloch+throws+clause+unchecked&source=bl&ots=y_HoMgr2Q0&sig=ACfU3U2ffB7Nq_sS4VAFz0vVACe8fPT8WA&hl=fr&sa=X&ved=2ahUKEwiM0q-QncniAhUIY1AKHZm0CY4Q6AEwDHoECAkQAQ#v=onepage&q=effective%20java%20bloch%20throws%20clause%20unchecked&f=false > >> > >>> > >>> Kind regards > >>> Karl Heinz Marbaise > >>> > >>> [1]: > >>> https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=commitdiff;h=6bfaf0653730bc8edc701b4e34f24d04adbaa78a > >>> [2]: https://travis-ci.org/apache/commons-geometry/builds/540087047 > >>> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
