User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
If an interface would work for ErrorCode, then that would be good.
However, I'd have to look into it.
FindBugs is picky about some odd things, but I've definitely found
bugs that would be hard to find otherwise. Coverity Scan is also
available to us and finds even more bugs.
FindBugs is sometimes wrong. When it is, I add a comment about why
I think it is wrong to the code.
Adding FindBugs was easy, I just added the following to the
<plugins>...</plugins> section of the toplevel pom.xml
Running "mvn findbugs:gui" brings up the FindBugs gui for each
package.
Then I configured Hudson to generate FindBugs reports for and to
look for **/findbugsXml.xml files.
I'll work on generating JavaDoc files next, then running doccheck to
find problems with the JavaDoc.
_C
On 1/25/16 12:46 PM, Jay Jay Billings
wrote:
W.r.t to ErrorCode, personally I always use an
interface for this type of thing. Gets around this naming
problem and decreases branching on the flip side too.
I need to get ICE building on the CBI and hook
FindBugs up to it. We use SonarQube internally but I'd
interested in seeing what FindBugs... er... finds.
I've checked the report
and there are definitely a series of warnings that I want to
have resolved.
Good idea to add it in our build!
cheers
erwin
Op 25/01/2016 om 21:26 schreef Erwin de Ley:
Hi Christopher,
I agree that we should follow all kinds of good practices,
and FindBugs probably has a valid set of them in its
default rules.
But... for the ErrorCode naming I'm a bit afraid to end up
with many long names for each extension of the base
ErrorCode pseudo-enum.
And that this could reduce readability of code i.o.
improving it.
E.g. for a typical usage of an extended ErrorCode such as
org.eclipse.triquetrum.processing.ErrorCode : in
DefaultTaskProcessingBroker there is a line like :
futResult.completeExceptionally(new
ProcessingException(ErrorCode.TASK_UNHANDLED, "No service
found for " + task, null));
I think this is quite readable, and better than e.g.
futResult.completeExceptionally(new
ProcessingException(ProcessingErrorCode.TASK_UNHANDLED,
"No service found for " + task, null));
We could maybe start using static imports if we go for the
specialized names? Then such code would become
futResult.completeExceptionally(new
ProcessingException(TASK_UNHANDLED, "No service found for
" + task, null));
Personally I'm not fond of static imports, but I see many
of our younger developers using them, so maybe I'm just a
bit old-fashioned ;-)
What do you think?
regards
erwin
Op 25/01/2016 om 20:44 schreef Christopher Brooks:
ErrorCode.java:26,
NM_SAME_SIMPLE_NAME_AS_SUPERCLASS, Priority:
High
The class name
org.eclipse.triquetrum.validation.ErrorCode
shadows the simple name of the superclass
org.eclipse.triquetrum.ErrorCode
This class has a simple name that is
identical to that of its superclass, except
that its superclass is in a different
package (e.g., alpha.Foo
extends beta.Foo). This can be
exceptionally confusing, create lots of
situations in which you have to look at
import statements to resolve references and
creates many opportunities to accidently
define methods that do not override methods
in their superclasses.
One fix would be to rename
org.eclipse.triquetrum.validation.ErrorCode to
org.eclipse.triquetrum.validation.ErrorCodeValidation or
something.
Or, we could ignore it.
I've found that fixing as many FindBugs warnings as
possible is really helpful because it makes the actual
bugs standout. The downside of fixing these bugs is
that some of the changes are not natural.
What are your thoughts?
_Christopher
--
Christopher Brooks, PMP University of California
Academic Program Manager & Software Engineer US Mail: 337 Cory Hall
CHESS/iCyPhy/Ptolemy/TerraSwarm Berkeley, CA 94720-1774
cxh@xxxxxxxxxxxxxxxxx, 707.332.0670 (Office: 545Q Cory)
--
Christopher Brooks, PMP University of California
Academic Program Manager & Software Engineer US Mail: 337 Cory Hall
CHESS/iCyPhy/Ptolemy/TerraSwarm Berkeley, CA 94720-1774
cxh@xxxxxxxxxxxxxxxxx, 707.332.0670 (Office: 545Q Cory)