On Jun 11, 2012, at 11:37 PM, Sean Owen wrote: > I myself am only advocating turning on *editor* support for avoiding even > writing problems to begin with. I actually agree that post-commit hooks can > be hard to use (error #39, stray space on line 319 of file X.java, now > where is that...) and noisy. I don't want that burden. > > I am merely surprised to see funny-looking Java code since, for Java, there > has always been one standard across the industry from the start (Sun's), > and with editor support, you kinda have to *try* to write such code. I do > think tools matter in this regard; IntelliJ is more seamless in > finding/fixing stuff but Eclipse does fine here too. Anything like > Sun-style Java would be great; what's being committed is not nearly.
I've always used the Lucene one that we publish. I think the only difference is it uses a tab/space size of 2 instead of 4. We should probably just make sure we publish the Eclipse and IntelliJ ones we want people to use and make sure all committers use them. > > > Style isn't important per se; it's a broken-windows thing. If nobody's > bothered about keywords or C-style arrays, it's a good chance people aren't > bothered about stuff static analysis can find. And that is correct here. > Again -- I'm advocating things that just make these non-issues at time of > writing. No hard work. It's hard to use the wrong variable in a loop when > the IDE flags it, or says "this cast can't be right" or "'transient' > doesn't make sense here" (Again: IntelliJ simply does this a mile better > than Eclipse. I do think it shows when you use an IDE that flags this, and > when you don't. FWIW -- IntelliJ dominated at Google.) Is there a way in IntelliJ to publish what ones you have turned on? It looks like in IntelliJ at least, one can publish their inspections. Sean, perhaps you can upload yours to the Wiki and we can all start from that one, or at least the IntelliJ users can and someone can port it to Eclipse. > > > Even this isn't as important per se as the real problems: the code just > looks un-designed or at best differently designed in most every major > package. Rotting code, deprecated APIs, incomplete stuff, TODO, a mile of > copy-and-paste in Bayes, three different frameworks for the same thing > (collections, Hadoop jobs, serialization). I get the first ones, what's the issue on Bayes (was it the two different implementations?) and the 3 frameworks? > This is a real problem and tools > won't detect this one. But when you aren't worried about formatting and > small bugs, when you can refactor with tool support that much more easily > -- you do. When it's hard you don't, and others don't. And that's been > borne out here. > > > I sense consensus that all this doesn't really matter so much, yes -- that > is why it is this way indeed. My years of seeing bad software and good tell > me that small-scale quality correlate with, and cause, big-scale quality. > At this point I don't know that it is worth really 'fixing' Mahout; it will > be superseded in a year or two anyway having accomplished some mission. But > it still doesn't hurt to start chipping away, from the small stuff. I will > stop tilting at this windmill since I'm not going to do new development in > Mahout anyway. Mea culpa on this one. I think I used to be the big blocker on this, but I've come to see the light, so I'm all for us taking this on. I do think there is still hope and it means we continue to focus more on our core capabilities and it likely starts with what the "broken windows" problem you are addressing here as well as the clean up and eviction of bad existing code instead of adding new code. I think we've started on this lately, but obviously we need to continue this momentum for it to be real.
