[EMAIL PROTECTED]
-Original Message-
From: Brian McCallister [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 26, 2003 7:35 AM
To: Jakarta General List
Subject: turbine-torque-user list
I apologize for sending to this list, but both
[EMAIL PROTECTED] and
[EMAIL
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 went from 1421 unused imports to
2 in the last month.
Yours,
Tom
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
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 something
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
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, doSomething
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, I'm the
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
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
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
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 went
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
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:
Hi Dion -
I'm using JavaNCSS - http://www.kclee.com/clemens/java/javancss/ - v21.41.
But I'm only scanning jakarta-turbine-maven/src/java:
[EMAIL PROTECTED] jakartafun]$ find jakarta-turbine-maven/ -name *.java |
wc -l
256
[EMAIL PROTECTED] jakartafun]$ find
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 code,
On Wed, 26 Feb 2003, O'brien, Tim wrote:
Date: Wed, 26 Feb 2003 19:12:51 -0600
From: O'brien, Tim [EMAIL PROTECTED]
Reply-To: Jakarta General List [EMAIL PROTECTED]
To: 'Jakarta General List' [EMAIL PROTECTED]
Subject: Karma request jakarta-site2
Was trying to add my name to the
16 matches
Mail list logo
