Mailing-List: contact dev-help@mahout.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mahout.apache.org
Received-SPF: pass (nike.apache.org: domain of srowen@gmail.com designates
 209.85.213.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4FD67A46.7060904@windwardsolutions.com>
References: 
 <CAEccTyxeaZxWVwcdd4XTEqzov3=1oS1ub5cs6kW5ZQKbcmv9_g@mail.gmail.com>
	<DCEAAE5B-48F9-4821-B9AE-2226F97571F7@apache.org>
	<CAB+3LJ=nwY=om1tCgbigh-N2Nex0LqheJAjgX6bztscGcBDY=Q@mail.gmail.com>
	<CALhtWkcApM2nHAjqXBkOOAZ6KM4on7Km-ys6cXk=xGu6=O1EAw@mail.gmail.com>
	<CAGRe5hRAbAePVpnE9+DPMwGt-Ot=3vQNyVsdiGP5M89_06ZNaQ@mail.gmail.com>
	<CALhtWkcYkLEF-Y6npqq9v7bMix04Kp0vmyqfL2r1WV2ypn-wPQ@mail.gmail.com>
	<4FD6014F.6070704@windwardsolutions.com>
	<CAPud8Tqr-D9wBTWoda6md=O-ryk3P+KzziwZd7jQk=Vdpas6Pw@mail.gmail.com>
	<CAPud8Tp-435LBOdZknqSCjS=tCnsu6ZK1C23MW6THZp+6_K4Xg@mail.gmail.com>
	<CAJwFCa2SNRjqxZB9ar8QjyJUhEtFuf=X6Np4xnEbODTCpDZyoA@mail.gmail.com>
	<CAPud8TpaEdq9dHB5QhYnONUvcF-Wt0R-D+9tFXRjV8vR5KQKOQ@mail.gmail.com>
	<CAPud8TqUCfR1o=8b+3jE9QO-bMvS22nuJedAFHM2Oq2P8QGjVw@mail.gmail.com>
	<4FD67A46.7060904@windwardsolutions.com>
Date: Tue, 12 Jun 2012 07:37:02 +0100
Message-ID: 
 <CAEccTyyR_hFgX31x4UtFrTB6XBUMc96FdR2Sw2rMPcPQPzKcRA@mail.gmail.com>
Subject: Re: Turn on code inspections, please
From: Sean Owen <srowen@gmail.com>
To: dev@mahout.apache.org
Content-Type: multipart/alternative; boundary=14dae9340395c3362a04c240b1d9

--14dae9340395c3362a04c240b1d9
Content-Type: text/plain; charset=UTF-8

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.
>
>

--14dae9340395c3362a04c240b1d9--