Find println's that are not needed

Would it be useful to anyone (other than me:) for intellij to find System.err and System.out statements that are

A. Not in the catch block of an exception
B. Not part of a conditional loop

In the projects I work on these statements are usually debug statements that need to be removed before a test build is created.

7 comments
Comment actions Permalink

I would absolutely use an inspection that found all uses of System.out and System.err, specifically for getting rid of debugging instrumentation.

0
Comment actions Permalink

charles decroes wrote:

Would it be useful to anyone (other than me:) for intellij to find System.err and System.out statements that are

A. Not in the catch block of an exception
B. Not part of a conditional loop

In the projects I work on these statements are usually debug statements that need to be removed before a test build is created.


We use a static code analysis (BCEL) JUnit test case that runs during
the nightly build to find all uses of System.out, System.err,
FileDescriptor.out, FileDescriptor.err and Throwable.printStackTrace and
flag them as errors since we have a log system that should be used instead.

It's actually quite useful to use BCEL to analyse your compiled classes
because you can do all sorts of interesting tests like cross-package
dependencies, class implements both hashCode and equals, empty catch
blocks which don't reference the Exception caught (it should be logged),
etc.

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://java.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: 416-643-4846 | Fax: 416-594-1919

0
Comment actions Permalink

You could just look for System.out usages, no?
"Dave Griffith" <dave.griffith@cnn.com> wrote in message
news:9542974.1053722223719.JavaMail.jrun@is.intellij.net...

I would absolutely use an inspection that found all uses of System.out and

System.err, specifically for getting rid of debugging instrumentation.


0
Comment actions Permalink

you could but i was looking for system.out and system.err that were not in catch blocks or surrounded by an if statement. Inside of catch or if is probably a legit statement , I'm not sure how useful it would really be that's why i'm asking

0
Comment actions Permalink

Sure, and I do, when I remember. Putting it in as a code inspection would allow me to automate the process, make it less likely to be forgotten, and remind me to keep on top of the problem throughout the coding cycle, not just when going through a pre-build manual checklist.

Something that IntelliJ project management has never gotten is that inspections may be valuable even if they were pretty simple, or show information that can be found other ways. Thus we have inspections for "Parameter can be final" (cool to code, minimal value in terms of actually lowering defect rates), but not "Empty Catch Block" (probably trivial to code, immense value in lowering defect rates). An inspection for flagging usages of System.out and System.err is another easy and valuable.

--Dave

0
Comment actions Permalink

On Sat, 24 May 2003 12:00:24 +0000, Dave Griffith wrote:

Sure, and I do, when I remember. Putting it in as a code inspection would
allow me to automate the process, make it less likely to be forgotten, and
remind me to keep on top of the problem throughout the coding cycle, not
just when going through a pre-build manual checklist.


Conversion to either log4j or jdk1.4 logging could be cool as well.

--
...turn to the light - don't be frightened by the shadows it creates,
...turn to the light - turning away could be a terrible mistake
...dream theater - the great debate


0
Comment actions Permalink

We've solved a similar problem by using a very simple (home grown so far, we
intend to switch to log4j in the near future) logging service. All the
calls to System.out.println issued from outside the logging
package are illegal, and they are removed periodically.

As for enforcing the policy of not using the System.out anywhere else (so
you don't have to search for them), I'm waiting for IntelliJ to open the
AspectJ integration, one of it's simplest utilizations (presented in most
tutorials) is this policy enforcement.

Andrei

Dave Griffith wrote:

Sure, and I do, when I remember. Putting it in as a code inspection would
allow me to automate the process, make it less likely to be forgotten, and
remind me to keep on top of the problem throughout the coding cycle, not
just when going through a pre-build manual checklist.

Something that IntelliJ project management has never gotten is that
inspections may be valuable even if they were pretty simple, or show
information that can be found other ways. Thus we have inspections for
"Parameter can be final" (cool to code, minimal value in terms of actually
lowering defect rates), but not "Empty Catch Block" (probably trivial to
code, immense value in lowering defect rates). An inspection for flagging
usages of System.out and System.err is another easy and valuable.

--Dave



0

Please sign in to leave a comment.