April 25, 2006

Programming in the small - warnings.

Following on from the previous article in the series, another "programming in the small" thing that annoys me is when warnings from the IDE are ignored.

This is more a matter of taste than previous articles - but it is based on reasoning rather than following a cargo cult.

The use of warnings

If you look at the warnings from your IDE, they sometimes indicate the chance to do the best refactoring - deleting code. Eclipse, for example, will warn of unused imports, unassigned fields, and uncalled private methods. These are warnings I want developers to act on - and delete unused code. Unused code is code you might accidentally read, keep compiling, or slow you down from seeing the code that's actually used.

Crying wolf

Sometimes IDEs provide warnings for things that aren't really a problem. The result of that is that in a lot of teams, developers just ignore all warnings, as the IDE has "cried wolf" too many times for warnings to be taken seriously any more.

I like to set the warnings of the IDE such that the ones I'm interested in are switched on, and the ones that cause "false positives" are switched off. I prefer to have no warnings at all, with some warnings that might sometimes be useful switched off, than to have more warnings but have to ignore some of them.

It's much easier to tell if a new warning has appeared when there are usually none. If you don't have the "false positive" warnings switched off (because you want some warning that is sometimes useful) the problem is that then you've got to remember which of the warnings you've got are the "false positive" ones, which can waste your time looking through them.

Don't check-in warnings

If the warnings are set such that there are no "false positives", then you know that if there are any warnings, you need to take notice of them, see what they are saying, and take action. Therefore, with warnings set appropriately, the team can follow a simple rule of not checking-in warnings - just like they wouldn't check-in compilation errors or code that failed the automated tests.

I want more warnings

If you have no warnings in your code, it makes it much more amenable to running the splendid "find bugs" Eclipse plug-in. If you start off with no warnings, then you can run "find bugs" and know that all of the warnings are "find bugs" ones. Although "find bugs" is really good - it can produce too many "false positives" for me to want to run it all the time or to have a "don't check in warnings" policy apply to "find bugs" warnings, so I only run and look at "find bugs" warnings occassionally.

I'll tell you what I want, what I really, really want.

It would be great if Eclipse (or other IDEs) (and "find bugs") allowed you to ignore specific warnings - not just types of warnings. Then you could have the warnings set higher, and ignore "false positives" (that you have checked manually once) so you don't have to switch "often useful but sometimes bogus" warnings off.

Posted by ivan at April 25, 2006 7:20 AM
Copyright (c) 2004-2008 Ivan Moore