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. 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.) 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). 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. On Tue, Jun 12, 2012 at 12:07 AM, Jeff Eastman <[email protected]>wrote: > In my case the projects that actually generate revenue for me all use > Eclipse so I have little incentive to switch horses at this point. If we > are raising the bar on style so far that reasonable Eclipse tooling > generates build failures then I am opposed to this level of style checking. > I frankly think we are arguing about minutia and it is counterproductive. > >
