> I still don't understand what the hubub about unused imports is about.
The goal is not really to check for unused imports (it's a "nice-to-have") but
IMO to regularly (every night?) use a tool to check the quality of the code. If
you care about the details (like unused imports), chances are tha
> >assertTrue("Whoa, doSomething returned a non-Fred type!", doSomething()
> >instanceof Fred);
When the test fails, you don't have a lot of information (like the class
returned by doSomething) to debug your code.
Using JUnit-addons, you would code your assertion:
ObjectAssert.assertInstance
> Historically Checkstyle focuses more on coding standards and checks
> for things like Javadoc quality, brace placement, use of whitespace,
> number of parameters in methods, etc. It does find unused imports and
> other QA checks.
>
> PMD has more of a bent on analysing the meaning of the source c
PROTECTED]>
Sent: Wednesday, February 26, 2003 8:07 PM
Subject: Re: Another unused import statement report is out...
> Tom, how are you working out the LOC for Maven?
>
> I count approx 280 .java files in the source tree and at 4066 loc, that
> makes approx 15 loc per fil
Tom, how are you working out the LOC for Maven?
I count approx 280 .java files in the source tree and at 4066 loc, that
makes approx 15 loc per file. Either we're really efficient, or there's
something being missed.
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/
Simon Brooke wrote:
Do you have a tool for checking for unused imports? I know I have a lot of
them in my code, but weeding them takes time and time is something I'm always
short of...
There are a few - Tom's tool, PMD, will do it, while checkstyle will also do
it.
Conor
---
on what
you are wanting to achieve (and how quickly) as to which one to use.
Regards,
Oliver
- Original Email -
From: Simon Brooke <[EMAIL PROTECTED]>
To: Jakarta General List <[EMAIL PROTECTED]>
Date: 27-Feb-2003 07:25
Subject: Re: Another unused import statement report is
If you hate unused imports, eclipse (and probably some of the other
newer IDEs) support organisation of imports.
Simply right click on the root of your source tree, select "Organize
Imports" and it's done.
If you're looking for a stand-alone tool, CheckStyle is a good place to
start.
(There i
On Wednesday 26 Feb 2003 7:57 pm, Tom Copeland wrote:
> unused imports are down 40% since last November, crikey!
>
> http://cvs.apache.org/~tcopeland/jakarta_bad_imports.htm
>
> Past reports can be found here - http://cvs.apache.org/~tcopeland/, and
> mad props to the xml-xalan project, who wen
> It gets my vote too. I'll use it on Commons projects and see if I get
> complaints etc.
>
I had never even heard of that way of doing the tests - I mean, with a
built in failure message thing - until recently when somebody suggested
it as a PMD rule. It's a good idea, although I haven't actual
On Wed, 26 Feb 2003, Daniel F. Savarese wrote:
>
> In message <[EMAIL PROTECTED]>, "Tom Copeland" writes:
> >assertTrue("Whoa, doSomething returned a non-Fred type!", doSomething()
> >instanceof Fred);
>
> I retract my comment about needing to do something with the variable.
> Tom's comment her
On Wed, 26 Feb 2003, Howard M. Lewis Ship wrote:
> I still don't understand what the hubub about unused imports is about.
I think it's clean, but if a public report is made on code and shows
somethign that is wrong with the code, then I'm happy to put the effort
into fixing it. Especially if th
In message <[EMAIL PROTECTED]>, "Tom Copeland" writes:
>assertTrue("Whoa, doSomething returned a non-Fred type!", doSomething()
>instanceof Fred);
I retract my comment about needing to do something with the variable.
Tom's comment here, in my opinion, is the best approach.
daniel
In message <[EMAIL PROTECTED]>, Hen
ri Yandell writes:
>Basically. Except it's:
>
>Fred fred = (Fred)doSomething(); in some cases.
Shouldn't you actually do something with the result as a precaution
to ensure the assignment doesn't get optimized out (either by the JIT
or the compiler)? (Or make
> I still don't understand what the hubub about unused imports is about.
> Tapestry is pretty clean of them, but even if it wasn't, I
> wouldn't say that
> code quality suffered. I mean, there's some fractional difference in
> compile speed I guess, and a tiny difference in code
> comprehension
>
> Perhaps test code should not be analysed at all. In
> HttpClient we are
> rigorus about imports (and style in general) in production
> code, but are
> more lax in test code. Not that test code is in anyway
> unimportant, but
> just has a different purpose than production code.
>
Yup,
>
> Basically. Except it's:
>
> Fred fred = (Fred)doSomething(); in some cases.
>
Hmmm it seems like that local variable is unnecessary if it's not
being used later on if this is a JUnit test and it's meant to ensure
a certain type is return, seems like this:
assertTrue("Whoa, doSomet
I still don't understand what the hubub about unused imports is about.
Tapestry is pretty clean of them, but even if it wasn't, I wouldn't say that
code quality suffered. I mean, there's some fractional difference in
compile speed I guess, and a tiny difference in code comprehension that is
comple
Perhaps test code should not be analysed at all. In HttpClient we are
rigorus about imports (and style in general) in production code, but are
more lax in test code. Not that test code is in anyway unimportant, but
just has a different purpose than production code.
Henri Yandell wrote:
On We
On Wed, 26 Feb 2003, Tom Copeland wrote:
> Hi Henri -
>
> Hm, I'm sorry, I don't understand the TestCase thing... are you doing
> something like:
>
> import junit.framework.*;
> public class FooTest extends TestCase {
> public void testFiddle() {
> Object obj = doSomething();
> }
> }
>
> or
rts for taglibs offline
Yours,
Tom
> -Original Message-
> From: Henri Yandell [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 26, 2003 3:09 PM
> To: Jakarta General List
> Subject: Re: Another unused import statement report is out...
>
>
>
> Anyway of
Anyway of turning off the:
"Avoid unused local variables such as 'obj'"
for classes which extend TestCase?
It's not something to avoid in a TestCase, as it tests the type of the
returned value. These warnings make it hard to see the real problems.
Even if it's only a grep for TestCase.java and
22 matches
Mail list logo