RE: Another unused import statement report is out...
> 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 that you care about more important things (like tests, unused variables, unused methods...). Once all the projects have discovered PMD (or another similar tool) and that the unused imports are fixed, we can report other (more interesting) things like unused variables, unused private methods, use interfaces in signatures, define at least one constructor... This will really increase the quality/readability of the code. The "unused imports" stuff is just the beginning, not the end. My 2 cents -Vladimir -- Vladimir R. Bossicard www.bossicard.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another unused import statement report is out...
> >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.assertInstanceOf(Fred, doSomething()); The error message will be something like: "expected instance of class: but was of class " at least you have something to start your debug session. -Vladimir PS: junit-addons.sf.net -- Vladimir R. Bossicard www.bossicard.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another unused import statement report is out...
> 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, > to find unused imports, variables, methods + plus other tests. Hence > it is slower than Checkstyle. > > There is a degree of overlap between them both. It depends on what > you are wanting to achieve (and how quickly) as to which one to use. > Yup! Right on. If you grep either the Checkstyle or the PMD code, you'll find several places where we've borrowed ideas from each other. I know I;ve put some comments in the PMD code like "Props to the Checkstyle guys for this Ant formatter gizmo which I've copied from their code". :-) Yours, tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another unused import statement report is out...
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 jakarta-turbine-maven/src/java -name "*.java" | wc -l 81 [EMAIL PROTECTED] jakartafun]$ so I think that's the difference... Yours, Tom - Original Message - From: <[EMAIL PROTECTED]> To: "Jakarta General List" <[EMAIL 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 file. Either we're really efficient, or there's > something being missed. > -- > dIon Gillard, Multitask Consulting > Blog: http://www.freeroller.net/page/dion/Weblog > Work: http://www.multitask.com.au > > > "Tom Copeland" <[EMAIL PROTECTED]> wrote on 27/02/2003 06:57:50 AM: > > > 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 Copeland > > InfoEther > > 703-486-4543 > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 file. Either we're really efficient, or there's something being missed. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au "Tom Copeland" <[EMAIL PROTECTED]> wrote on 27/02/2003 06:57:50 AM: > 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 Copeland > InfoEther > 703-486-4543 > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another unused import statement report is out...
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another unused import statement report is out...
Simon, There are numerous tools you can use. The two main ones available are: - Checkstyle (http://checkstyle.sf.net) - PMD (http://pmd.sf.net) 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, to find unused imports, variables, methods + plus other tests. Hence it is slower than Checkstyle. There is a degree of overlap between them both. It depends 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 out... > 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 from 1421 unused imports to > > 2 in the last month. > > 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... > > -- > [EMAIL PROTECTED] (Simon Brooke) http://www.jasmine.org.uk/~simon/ > > See one nuclear war, you've seen them all. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another unused import statement report is out...
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 is an eclipse plugin for CheckStyle - so you can see style violations while coding - if you so desire) Simon Brooke wrote: 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 from 1421 unused imports to 2 in the last month. 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... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another unused import statement report is out...
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 from 1421 unused imports to > 2 in the last month. 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... -- [EMAIL PROTECTED] (Simon Brooke) http://www.jasmine.org.uk/~simon/ See one nuclear war, you've seen them all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another unused import statement report is out...
> 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 actually gotten around to modifying all the PMD unit tests to do that; they all still use the short version "assert(foo)". Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another unused import statement report is out...
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 here, in my opinion, is the best approach. It gets my vote too. I'll use it on Commons projects and see if I get complaints etc. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another unused import statement report is out...
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 the report is going to be run periodically such that I'll be able to trust the report to keep the code honest in the future. If someone had an online report from Clover generating, I would happily do the same. I know Clover hooks into Maven, so hopefully I can get that running someday. > 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 It helps to keep it neat mainly. Usage of import xx.* is far worse in my opionated view :) Especially for open-source projects that people will be reading the source of a lot. > compile speed I guess, and a tiny difference in code comprehension that is > completely eclipsed by decent comments and JavaDoc. There are other tools > out there that do a better job of analyzing the code itself for > deficiencies. Yep. But their creators don't come along to the list and provide people with the metric. > I'd much rather see folks working to create JUnit test suites and publishing > their code coverage results. Tapestry uses a framework called Clover, which > is free for open source projects and produces a pretty result (using > Velocity, btw). > > http://jakarta.apache.org/proposals/tapestry/doc/clover/ > > I'm very proud of the 80% coverage (on 23K NCLOC, 23000 lines of code > excluding comments) and expect to push this to 90% before 2.4 GAs. Yeah, it's kicking around on my long list of "Things to learn". Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another unused import statement report is out...
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another unused import statement report is out...
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 sure tests are compiled and run with no optimizations and no jit with a compiler and jvm with well-understood behavior.) In any case, all metrics reports have to be taken with a grain of salt and interpreted by a human rather than blindly trusted as indications of errors. So any general out of the box configuration is not going to be suitable for all subprojects. One thing subprojects that rely on Tom's PMD reports could do is adjust their Gump descriptors (or just their build files) so that Gump will run PMD using their custom PMD configuration and generate subproject-specific reports on a daily basis. But I guess that would require Gump to publish the reports. Short of developing a comprehensive opt-in cross-subproject process plan, I think Gump's a good place to focus this sort of stuff so ad hoc process additions that require asynchronous recurrent generation of artifacts are localized in a single place. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another unused import statement report is out...
> 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 > completely eclipsed by decent comments and JavaDoc. There > are other tools > out there that do a better job of analyzing the code itself for > deficiencies. True! The reason I send these reports to the list is that: # it's easy - the report takes about 10 minutes to create # it occasionally triggers good discussions like the current one # it's fun to see all the projects side by side in any kind of view # it kind of lightens things up sometimes > > I'd much rather see folks working to create JUnit test suites > and publishing > their code coverage results. Tapestry uses a framework > called Clover, which > is free for open source projects and produces a pretty result (using > Velocity, btw). > > http://jakarta.apache.org/proposals/tapestry/doc/clover/ > > I'm very proud of the 80% coverage (on 23K NCLOC, 23000 lines of code > excluding comments) and expect to push this to 90% before 2.4 GAs. > I totally concur that unit tests are far more important than unused imports, and I applaud your unit test coverage. 80% is awesome. Yours, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another unused import statement report is out...
> > 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 same way - I'm much more likely to copy and paste test code than I am "real" code. On the other hand, that usually comes back to bite me at some point when I have to change stuff. But, I know what you mean. Actually, for most of these reports: http://cvs.apache.org/~tcopeland/pmdweb/ I only run PMD on the foomodule/java/src directory, so I usually end up missing the tests. The jakarta-taglibs project, though, has a whole bunch of directories right under the module, so it's not as easy to separate the production code out... And, of course, this is only a rough scan, PMD has a couple of bugs that can occasionally return false positives, so your mileage may vary and all that. It's still pretty accurate though :-) Yours, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another unused import statement report is out...
> > 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 returned a non-Fred type!", doSomething() instanceof Fred); That way you'll get a nice error message rather than just a ClassCastException if the test fails. > When I raised the discussion a while back on removing these > [based on your > error reporting] there was a view that the above improves the testing, > even if it is not usually considered good style. > > So I'm looking for a configuration change in the Jakarta > Commons/Sandbox > [at least] reporting which removes these and makes it easier > to focus on > the real problems. > Does the above assertTrue() thing work for you? Or maybe I'm not understanding the problem completely... Yours, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another unused import statement report is out...
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 completely eclipsed by decent comments and JavaDoc. There are other tools out there that do a better job of analyzing the code itself for deficiencies. I'd much rather see folks working to create JUnit test suites and publishing their code coverage results. Tapestry uses a framework called Clover, which is free for open source projects and produces a pretty result (using Velocity, btw). http://jakarta.apache.org/proposals/tapestry/doc/clover/ I'm very proud of the 80% coverage (on 23K NCLOC, 23000 lines of code excluding comments) and expect to push this to 90% before 2.4 GAs. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/proposals/tapestry > -Original Message- > From: Tom Copeland [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 26, 2003 2:58 PM > To: [EMAIL PROTECTED] > Subject: Another unused import statement report is out... > > > 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 Copeland > InfoEther > 703-486-4543 > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another unused import statement report is out...
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 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 else? Basically. Except it's: Fred fred = (Fred)doSomething(); in some cases. When I raised the discussion a while back on removing these [based on your error reporting] there was a view that the above improves the testing, even if it is not usually considered good style. So I'm looking for a configuration change in the Jakarta Commons/Sandbox [at least] reporting which removes these and makes it easier to focus on the real problems. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another unused import statement report is out...
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 else? Basically. Except it's: Fred fred = (Fred)doSomething(); in some cases. When I raised the discussion a while back on removing these [based on your error reporting] there was a view that the above improves the testing, even if it is not usually considered good style. So I'm looking for a configuration change in the Jakarta Commons/Sandbox [at least] reporting which removes these and makes it easier to focus on the real problems. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another unused import statement report is out...
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 else? I'll email you the unused imports 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 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 'unused local > variable' to > filter these lines out :) > > Also, do you have a list of the unused imports for the test below? > I was going to do some cleaning up in Taglibs, but can't see the list. > > Thanks, > > Hen > > On Wed, 26 Feb 2003, 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 from 1421 unused imports to > > 2 in the last month. > > > > Yours, > > > > Tom Copeland > > InfoEther > > 703-486-4543 > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another unused import statement report is out...
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 'unused local variable' to filter these lines out :) Also, do you have a list of the unused imports for the test below? I was going to do some cleaning up in Taglibs, but can't see the list. Thanks, Hen On Wed, 26 Feb 2003, 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 from 1421 unused imports to > 2 in the last month. > > Yours, > > Tom Copeland > InfoEther > 703-486-4543 > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]