(It is recommended you read this with good humor, like Think Geek)
While building Netbeans, a number of warnings show up. We should fix that.
For the sake of organization, we should probably open a new task for each module. This will be the root/umbrella task. The main project heads should take a look at this task and update it with official stuff.
We should probably slay warnings in this order:
- Warnings that don't require changes to other modules (like API changes). Examples would be changing raw types to non-raw types or something that would cause another module to not build after the warning has be properly dealt with.
- Warnings that Do require changes to other modules (see previous entry for examples)
- Those evil warnings that don't leave any links behind. Here are some examples:
The following guide-lines should be followed while slaying warnings:
- You shall make every effort to resolve the warning without suppressing it. This may involve one or more of the following (non-inclusive):
- Adding a new variable so assignments are not done to method parameters
- Adding a variable followed with an "assert var != null" to let the IDE know that it can't be null
- In the second pass, breaking APIs so raw types and such are not used if possible
- You shall suppress the warning on the smallest scope possible. Why? Warnings exist for a reason. They are there to tell you that you did something wrong, unless that was your intention and you know what you are doing. That is what @SuppressWarnings is for. If (heaven forbid) you suppress all warnings in a class file, you may be (figuratively) slain, so DON'T!
- The following (in my opinion) is a good way to suppress a warning on a line:
- You may want to add dummy return values to some void methods to enable suppression via the above method.
- If you do suppress a warning, and it is not obvious why it was suppressed, document it! Leave a comment that says why it was suppressed. The following is an example:
I think that is all for now...