mahout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Owen <sro...@gmail.com>
Subject Re: Turn on code inspections, please
Date Tue, 12 Jun 2012 06:37:02 GMT
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
<jdog@windwardsolutions.com>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.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message