Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > ArrayList.Iterator.remove()

Reply
Thread Tools

ArrayList.Iterator.remove()

 
 
Arved Sandstrom
Guest
Posts: n/a
 
      07-02-2009
Lew wrote:
> Lew wrote:
>>> Could someone please point to a FinalReference reference?

>
> Arved Sandstrom wrote:
>> I couldn't find one myself. Looking at the code for
>> java.lang.ref.Finalizer, which extends java.lang.ref.FinalReference,
>> is probably the best way to figure it out.

>
> So, once again, not a hidden *feature* but a hidden *implementation
> detail*.
>
> I thought one of the tenets of O-O programming was to hide
> implementation details.


Both Finalizer and FinalReference are package private in java.lang.ref,
so pretty clearly these are not classes that the masses are meant to
use. In other words, definitely implementation details.

AHS
 
Reply With Quote
 
 
 
 
Kevin McMurtrie
Guest
Posts: n/a
 
      07-03-2009
In article <op.uwf8p4lf8jd0ej@clampitt>,
"Peter Duniho" <(E-Mail Removed)> wrote:

> On Thu, 02 Jul 2009 08:07:59 -0700, Kevin McMurtrie <(E-Mail Removed)>
> wrote:
>
> > [...]
> > Compiler warnings are great for new code, but not so great for the
> > millions of lines of old code.

>
> I'd say they're pretty good for old code, even millions of lines, if you
> actually go _fix_ them.
>
> Sheer quantity of code isn't really a justification for leaving errors in
> it.


Tell your boss you want to spend a full year fixing Java 1.5 warnings
because there's a 1 in 600 chance that each is a bug. Next convince
your boss that the risk in fixing them is lower than the original 1 in
600 odds.

--
I will not see your reply if you use Google.
 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      07-03-2009
Peter Duniho wrote:
>> Sheer quantity of code isn't really a justification for leaving errors in
>> it.


Kevin McMurtrie wrote:
> Tell your boss you want to spend a full year fixing Java 1.5 warnings
> because there's a 1 in 600 chance that each is a bug. Next convince
> your boss that the risk in fixing them is lower than the original 1 in
> 600 odds.


Oh, yeah, leave the bugs in the code. That's a *real* professional attitude!

--
Lew
 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      07-03-2009
Patricia Shanahan wrote:
> Lew wrote:
>> Peter Duniho wrote:
>>>> Sheer quantity of code isn't really a justification for leaving
>>>> errors in it.

>>
>> Kevin McMurtrie wrote:
>>> Tell your boss you want to spend a full year fixing Java 1.5 warnings
>>> because there's a 1 in 600 chance that each is a bug. Next convince
>>> your boss that the risk in fixing them is lower than the original 1
>>> in 600 odds.

>>
>> Oh, yeah, leave the bugs in the code. That's a *real* professional
>> attitude!
>>

>
> I agree that it is a really professional attitude. *Every* change to
> code carries a risk of creating a bug. Clean existing code and a good
> development process reduce the risk, but it cannot be reduced to zero.
> Every change also has a cost in programmer time and effort that could
> have been spent on something else.
>
> I've seen important releases, with real bug fixes and features the users
> wanted, delayed because someone decided to clean up a harmless departure
> from technical desirability, and introduced a new bug in the process.
>
> A professional programmer should step beyond purely technical issues to
> think about whether the risk and cost associated with a change are
> justified by the benefit.
>
> I do not mean to imply one should never clean up warnings etc. I
> strongly prefer warning-free code. Neither the cost nor the benefit of
> clean-up is zero, so it is a non-trivial decision.
>
> Patricia


One thing I learned early in my career, which is related to this
subject, is, as much as it pains you to see spelling errors in method
names and variable names (for example, coders using "principal" when
they meant "principle", and vice versa, or "similiar" instead of the
correct "similar"), don't take advantage of your IDE's refactoring
capability to correct everything. It's amazing how badly this can
bite you.

In the larger sense I agree with Patricia. Once a piece of code is
baselined, you can see an obvious error staring you right in the face
while working on something else, but you have to resist the temptation
to fix it. Code somewhere else may rely on that error. You need to have
permission to make the fix, after explaining why you should fix it.

AHS
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      07-03-2009
Patricia Shanahan wrote:
> Lew wrote:
>> Peter Duniho wrote:
>>>> Sheer quantity of code isn't really a justification for leaving
>>>> errors in it.

>>
>> Kevin McMurtrie wrote:
>>> Tell your boss you want to spend a full year fixing Java 1.5 warnings
>>> because there's a 1 in 600 chance that each is a bug. Next convince
>>> your boss that the risk in fixing them is lower than the original 1
>>> in 600 odds.

>>
>> Oh, yeah, leave the bugs in the code. That's a *real* professional
>> attitude!
>>

>
> I agree that it is a really professional attitude. *Every* change to
> code carries a risk of creating a bug. Clean existing code and a good
> development process reduce the risk, but it cannot be reduced to zero.
> Every change also has a cost in programmer time and effort that could
> have been spent on something else.
>
> I've seen important releases, with real bug fixes and features the users
> wanted, delayed because someone decided to clean up a harmless departure
> from technical desirability, and introduced a new bug in the process.
>
> A professional programmer should step beyond purely technical issues to
> think about whether the risk and cost associated with a change are
> justified by the benefit.
>
> I do not mean to imply one should never clean up warnings etc. I
> strongly prefer warning-free code. Neither the cost nor the benefit of
> clean-up is zero, so it is a non-trivial decision.


What you suggest is valid and certainly not using "sheer quantity of code" as
a justification. However, the attitude that "mere" warnings are acceptable
does lead to real bugs that cause trouble in production. Where did Kevin's "1
in 600 chance" assessment come from? Statistical analysis? I feel certain
not, rather, it was pulled from a particular posterior region.

99% (another posteriorily postulated probability) of the time someone
recommends simply not fixing warnings they are ignoring real bugs.

I've seen this in my current large-team project and in past such projects,
where a request for customer A's data resulted in data from customer B's
records because people ignored "trivial" warnings, or merely left out simple
code analysis that would have revealed trouble that didn't raise a compiler
warning.

A professional programmer should step beyond purely arbitrary (and specious)
characterizations of risk and cost associated with a change to understand that
*every* failure to change code that has warnings carries a risk of
perpetuating a bug. I agree that risk cannot be reduced to zero, but leaving
known warnings in code increases that risk.

Code should not be released into the code base in the first place with
warnings showing. If that's done, then the question of the risk of change
becomes moot, because there's nothing to change. When that principle is
ignored, the technical debt mounts until people can aver that the "risk of
cleaning up" is too high to shoulder. In practice, I've seen much more
failure to perform correctly arise from leaving known bugs in than from
cleaning them up.

Once they're in, then the cost of repair is high, but there are mitigation
strategies even so. Again using my current project as an example, where we
have multiple warnings (from the compiler and from Findbugs, a /sine qua non/
for robust code) the reviewers recommend to management a strategy that cleans
up the most critical bugs right away, but defers others to a refactoring
timetable that also improves fundamental algorithms or updates to later
features (e.g., JPA over old-style ORM code). Combination strategies like
fixing the algorithm often reap much larger benefits than simple patches for
similar cost, including simplification of the code to reduce the risk of
introducing new bugs.

Just because one maintainer was careless with a fix doesn't mean that the fix
itself was a bad idea. Zero defects should be the goal rather than
resignation to poor quality. You can't use "it's impossible" as an excuse not
to aim for it. And you most certainly can't use arbitrary and unsupported
fake statistics to support a cost/benefit analysis.

--
Lew
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments