That sounds good. In that case, to implement this right, we'll need to build a real symbol table, complete with fully resolved external references and types. That's the next level, for sure....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
http://www.tcs.com/products/assent/htdocs/assent_rules.htm#java
The 'use equals() not ==' might be a good one.
The 'if you override equals(), override hashcode()' is good too.
Tom
The "override both equals and hashcode" one is done.
Tom
Another good one is "unused formal parameters are a bad sign". It's not always true, but it's kind of a code smell...
Tom
Unused Formals are perfectly all right, if they are
required by the Interface (or Abstract Method) but
aren't required.
For instance, every SAX parser on earth will have
trouble with this rule, as most of the parameters passed
are fluff.
I think Unused Formals are OK IF:
- Formal List is not declared by an Interface
- Formal List is not declared by a superclass
Otherwise, they are a smell.
That sounds good. In that case, to implement this right, we'll need to build a real symbol table, complete with fully resolved external references and types. That's the next level, for sure....