> Am 16.10.2017 um 00:34 schrieb Gilles <gil...@harfang.homelinux.org>: > > On Sun, 15 Oct 2017 14:45:09 -0500, Matt Sicker wrote: >> Assertion classes are just containers for static methods. Using "import >> static" is the only way in Java to import the individual methods as if the >> class itself were a package. Also, doing this is pretty common when using >> the Assert class as all its methods are prefixed with "assert" anyways. > > It's not because something is widespread that it should be emulated. > Is there any good reason to use "import static"? [Saving the typing > of 7 characters cannot be one of them.] > > It can (and does) happen that "assert..." methods are defined > on a per project basis, and nothing is gained when the reader > has to check the top of the file to be sure of what class is > actually used. > > My point was just that rather than cleaning up, the commit was > obfuscating (even if so little) the source code. > I prefer the other way around. :-)
I think there are pros and cons for both styles. I prefer static imports. I don’t see any value in knowing, that assertEquals comes from a class called Assert. Cheers, Benedikt > > YMMV, > Gilles > > >> On 15 October 2017 at 13:44, Gilles <gil...@harfang.homelinux.org> wrote: >> >>> On Sun, 15 Oct 2017 12:22:13 +0200, Pascal Schumacher wrote: >>> >>>> Just for consistency. >>>> >>> >>> Consistency is fine. ;-) >>> >>> All almost all tests already used static >>>> imports, so I adjusted the few that did not. >>>> >>> >>> It's the use of "import static" which I was questioning. >>> >>> Gilles >>> >>> >>> >>>> -Pascal >>>> >>>> Am 15.10.2017 um 11:44 schrieb Gilles: >>>> >>>>> On Sun, 15 Oct 2017 09:34:04 +0000 (UTC), pascalschumac...@apache.org >>>>> wrote: >>>>> >>>>>> Repository: commons-text >>>>>> Updated Branches: >>>>>> refs/heads/master 51645b4f0 -> 8f7d0494d >>>>>> >>>>>> >>>>>> always use static imports for assertion methods >>>>>> >>>>>> >>>>> Why? >>>>> >>>>> Gilles >>>>> >>>>> >>>>>> [...] >>>>>> >>>>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
