They drive me bananas and since I wrote a bunch of the original code, that probably accounts for the lack of static imports. There's no rule against them because, while I don't like them, I get that they're not overtly harmful.
My (arguably flawed) dislike of them is because: * I think it's clearer to see the name of the class static methods come from for documentation purposes. * It makes autocompletion in IDEs saner. * It future proofs against the creation of similarly named methods within the inheritance hierarchy. * It creates consistency across the codebase. * It provides no meaningful value (in my opinion) - I personally *always* prefer fewer alterations[1] to the normal language behavior to reduced typing. [1] Static imports effectively fly in the face of what we're taught about unqualified method invocation; that they're within the inheritance tree. It forces you to think of something different (some of the same issues with multiple inheritance). I would ask that we go one direction or another, though; I don't want to have to guess (or start looking at the import list) when I read the code. Of course, we're not going to statically import every static method so... (you see my personal dilemma) On Sat, Feb 25, 2012 at 10:30 PM, Brock Noland <[email protected]> wrote: > Static imports should always be used conservatively. However, there a > few classes that static imports make for a much more fluent style and > is a generally accepted practice: > > 1) Mockito > 2) JUnit Assert > 3) Guava Preconditions > > I have noticed that Flume does not use static imports but nothing is > mentioned on the wiki. Are we against static imports in the cases > above? > > Brock > > -- > Apache MRUnit - Unit testing MapReduce - > http://incubator.apache.org/mrunit/ > -- Eric Sammer twitter: esammer data: www.cloudera.com
