You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@commons.apache.org by se...@apache.org on 2010/10/01 15:35:49 UTC
svn commit: r1003533 -
/commons/proper/math/trunk/src/test/java/org/apache/commons/math/stat/regression/MultipleLinearRegressionAbstractTest.java
Author: sebb
Date: Fri Oct 1 13:35:49 2010
New Revision: 1003533
URL: http://svn.apache.org/viewvc?rev=1003533&view=rev
Log:
Unnecessary cast
Modified:
commons/proper/math/trunk/src/test/java/org/apache/commons/math/stat/regression/MultipleLinearRegressionAbstractTest.java
Modified: commons/proper/math/trunk/src/test/java/org/apache/commons/math/stat/regression/MultipleLinearRegressionAbstractTest.java
URL: http://svn.apache.org/viewvc/commons/proper/math/trunk/src/test/java/org/apache/commons/math/stat/regression/MultipleLinearRegressionAbstractTest.java?rev=1003533&r1=1003532&r2=1003533&view=diff
==============================================================================
--- commons/proper/math/trunk/src/test/java/org/apache/commons/math/stat/regression/MultipleLinearRegressionAbstractTest.java (original)
+++ commons/proper/math/trunk/src/test/java/org/apache/commons/math/stat/regression/MultipleLinearRegressionAbstractTest.java Fri Oct 1 13:35:49 2010
@@ -85,7 +85,7 @@ public abstract class MultipleLinearRegr
{25, 35, 45},
{27, 37, 47}
};
- AbstractMultipleLinearRegression regression = (AbstractMultipleLinearRegression) createRegression();
+ AbstractMultipleLinearRegression regression = createRegression();
regression.newSampleData(design, 4, 3);
RealMatrix flatX = regression.X.copy();
RealVector flatY = regression.Y.copy();
Re: [Math] Code review
Posted by Ted Dunning <te...@gmail.com>.
On Fri, Oct 1, 2010 at 3:22 PM, sebb <se...@gmail.com> wrote:
> On 1 October 2010 22:54, Ted Dunning <te...@gmail.com> wrote:
> > In Mahout, we have found that IntelliJ (which is usually like Eclipse,
> but
> > more thorough) does not warn on the same things
> > that findbugs, pmd or checkstyle warn on. We haven't been able to force
> > that behavior very well, either. That means that
> > we have to use a combination of methods to drive down warnings.
> >
> > In general, the quality of the maven mediated warnings is much lower than
> > the quality of the IDE based warnings although
>
> Findbugs (Maven) and Findbugs (IDE) should report the same problems.
> However, it's a lot easier to fix the problems when using an IDE.
Findbugs should be consistent, but IntelliJ has its own set of warnings
independent
of FindBugs. I can't comment on eclipse having never used it, but it was my
impression
that it had more than just FindBugs.
Re: [Math] Code review
Posted by sebb <se...@gmail.com>.
On 1 October 2010 22:54, Ted Dunning <te...@gmail.com> wrote:
> In Mahout, we have found that IntelliJ (which is usually like Eclipse, but
> more thorough) does not warn on the same things
> that findbugs, pmd or checkstyle warn on. We haven't been able to force
> that behavior very well, either. That means that
> we have to use a combination of methods to drive down warnings.
>
> In general, the quality of the maven mediated warnings is much lower than
> the quality of the IDE based warnings although
Findbugs (Maven) and Findbugs (IDE) should report the same problems.
However, it's a lot easier to fix the problems when using an IDE.
> there are a few exceptions (Eclipse flags @override all the time even when
> it is correctly done,
I find that Eclipse flags @Override correctly.
However, one does have to ensure that the Eclipse compiler settings are correct.
> findbugs flags certain serialization
> and maintainability problems better).
Agreed.
> On Fri, Oct 1, 2010 at 2:23 PM, Gilles Sadowski <
> gilles@harfang.homelinux.org> wrote:
>
>> This, I know. In fact I was surprised that Sebb uncovered so many problems
>> that were _not_ reported by FindBugs or Checkstyle. Hence my question: Can
>> there be additional Maven plugins that will report all the things which
>> Eclipse sees?
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Code review
Posted by Ted Dunning <te...@gmail.com>.
In Mahout, we have found that IntelliJ (which is usually like Eclipse, but
more thorough) does not warn on the same things
that findbugs, pmd or checkstyle warn on. We haven't been able to force
that behavior very well, either. That means that
we have to use a combination of methods to drive down warnings.
In general, the quality of the maven mediated warnings is much lower than
the quality of the IDE based warnings although
there are a few exceptions (Eclipse flags @override all the time even when
it is correctly done, findbugs flags certain serialization
and maintainability problems better).
On Fri, Oct 1, 2010 at 2:23 PM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:
> This, I know. In fact I was surprised that Sebb uncovered so many problems
> that were _not_ reported by FindBugs or Checkstyle. Hence my question: Can
> there be additional Maven plugins that will report all the things which
> Eclipse sees?
>
Re: [Math] Code review
Posted by Phil Steitz <ph...@gmail.com>.
On 10/2/10 3:25 PM, Ted Dunning wrote:
> Another option is to have a small community of activists who are willing to
> comb the code and improve it without requiring everybody to catch all these
> issues.
>
If what you mean by this is that we don't expect committers to fix
checkstyle / findbugs errors before committing code, that is a
logical option but not how we have worked in [math] up to now. As
the one who usually ends up having to RM, I am -1 on moving to this
approach. It is *much better* to keep the code clean when we check
it in, using the reports integrated into the build to flag issues
that we need to fix. If what you mean is that we should welcome
patches to make improvements beyond what is picked up by the static
analyzers in the build, I agree with that, as long as these patches
actually improve the code.
Phil
> On Sat, Oct 2, 2010 at 8:37 AM, Phil Steitz<ph...@gmail.com> wrote:
>
>> From my perspective, checkstyle.xml effectively represents our coding style
>> rules. I am fine with people making cosmetic changes that go beyond what is
>> specified in those checks, but I am -1 on requiring access to or specifying
>> usage of any specific IDE to ensure compliance with [math] coding standards.
>>
>> I am also fine with adding other static code analysis plugins such as
>> findbugs to point out potential bugs, as long as we maintain the associated
>> config files and uniformly either fix or manage exceptions. Here again,
>> tools need to be freely available and IDE-independent if we expect the
>> community to use them.
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Code review
Posted by Ted Dunning <te...@gmail.com>.
Another option is to have a small community of activists who are willing to
comb the code and improve it without requiring everybody to catch all these
issues.
On Sat, Oct 2, 2010 at 8:37 AM, Phil Steitz <ph...@gmail.com> wrote:
> From my perspective, checkstyle.xml effectively represents our coding style
> rules. I am fine with people making cosmetic changes that go beyond what is
> specified in those checks, but I am -1 on requiring access to or specifying
> usage of any specific IDE to ensure compliance with [math] coding standards.
>
> I am also fine with adding other static code analysis plugins such as
> findbugs to point out potential bugs, as long as we maintain the associated
> config files and uniformly either fix or manage exceptions. Here again,
> tools need to be freely available and IDE-independent if we expect the
> community to use them.
>
Re: [Math] Code review
Posted by Phil Steitz <ph...@gmail.com>.
On 10/1/10 5:23 PM, Gilles Sadowski wrote:
> On Fri, Oct 01, 2010 at 04:05:11PM -0500, Brent Worden wrote:
>> On Fri, Oct 1, 2010 at 9:27 AM, Gilles Sadowski
>> <gi...@harfang.homelinux.org> wrote:
>>>>> Do you review the code manually, or do you use a tool to spot all these
>>>>> potential problems?
>>>>
>>>> Eclipse reports these, and I inspect them manually before committing.
>>>
>>> Isn't there some plugin such as CheckStyle or FindBugs that could be called
>>> from maven?
>>
>> [...]
>>
>> To generate all reports, including checkstyle and findbugs, via Maven:
>> mvn site:site
>>
>> To generate checkstyle report:
>> mvn checkstyle:checkstyle
>>
>> To generate findbugs report:
>> mvn findbugs:findbugs
>
> This, I know. In fact I was surprised that Sebb uncovered so many problems
> that were _not_ reported by FindBugs or Checkstyle. Hence my question: Can
> there be additional Maven plugins that will report all the things which
> Eclipse sees?
>
One difference is that the findbugs and checkstyle reports do not
run against the test code. We could configure them to do that,
which would probably turn up *lots* of stuff that we could fix or
configure exceptions for.
From my perspective, checkstyle.xml effectively represents our
coding style rules. I am fine with people making cosmetic changes
that go beyond what is specified in those checks, but I am -1 on
requiring access to or specifying usage of any specific IDE to
ensure compliance with [math] coding standards.
I am also fine with adding other static code analysis plugins such
as findbugs to point out potential bugs, as long as we maintain the
associated config files and uniformly either fix or manage
exceptions. Here again, tools need to be freely available and
IDE-independent if we expect the community to use them.
Phil
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Code review
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Fri, Oct 01, 2010 at 04:05:11PM -0500, Brent Worden wrote:
> On Fri, Oct 1, 2010 at 9:27 AM, Gilles Sadowski
> <gi...@harfang.homelinux.org> wrote:
> >> > Do you review the code manually, or do you use a tool to spot all these
> >> > potential problems?
> >>
> >> Eclipse reports these, and I inspect them manually before committing.
> >
> > Isn't there some plugin such as CheckStyle or FindBugs that could be called
> > from maven?
>
> [...]
>
> To generate all reports, including checkstyle and findbugs, via Maven:
> mvn site:site
>
> To generate checkstyle report:
> mvn checkstyle:checkstyle
>
> To generate findbugs report:
> mvn findbugs:findbugs
This, I know. In fact I was surprised that Sebb uncovered so many problems
that were _not_ reported by FindBugs or Checkstyle. Hence my question: Can
there be additional Maven plugins that will report all the things which
Eclipse sees?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Code review
Posted by Brent Worden <br...@gmail.com>.
On Fri, Oct 1, 2010 at 9:27 AM, Gilles Sadowski
<gi...@harfang.homelinux.org> wrote:
>> > Do you review the code manually, or do you use a tool to spot all these
>> > potential problems?
>>
>> Eclipse reports these, and I inspect them manually before committing.
>
> Isn't there some plugin such as CheckStyle or FindBugs that could be called
> from maven?
>
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
To generate all reports, including checkstyle and findbugs, via Maven:
mvn site:site
To generate checkstyle report:
mvn checkstyle:checkstyle
To generate findbugs report:
mvn findbugs:findbugs
HTH,
Brent.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Code review
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> > Do you review the code manually, or do you use a tool to spot all these
> > potential problems?
>
> Eclipse reports these, and I inspect them manually before committing.
Isn't there some plugin such as CheckStyle or FindBugs that could be called
from maven?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Code review (Was: Re: svn commit: r1003533 - ...)
Posted by sebb <se...@gmail.com>.
On 1 October 2010 14:49, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
> Hi.
>
>> URL: http://svn.apache.org/viewvc?rev=1003533&view=rev
>> Log:
>> Unnecessary cast
>>
>> [...]
>
> Do you review the code manually, or do you use a tool to spot all these
> potential problems?
Eclipse reports these, and I inspect them manually before committing.
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[Math] Code review (Was: Re: svn commit: r1003533 - ...)
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
> URL: http://svn.apache.org/viewvc?rev=1003533&view=rev
> Log:
> Unnecessary cast
>
> [...]
Do you review the code manually, or do you use a tool to spot all these
potential problems?
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org