Top Ten Errors Java Programmers Make
Additya
surfing , it is about the ten common errors which may be made by any
Java Programmer while Programming. The article lists all those
mistakes and their solution.
http://www.ezdia.com/Top_Ten_Errors_Java_Programmers_make/Content.do?id=839
Roedy Green
wrote, quoted or indirectly quoted someone who said :
These might be the errors the author makes, but I doubt they are the
errors programmers make in general. For example forgetting the arrays
are 0-based is not likely unless your last language was FORTRAN, a
rather rare occurrence.
--
Roedy Green Canadian Mind Products
http://mindprod.com
I mean the word proof not in the sense of the lawyers, who set two half proofs equal to a whole one, but in the sense of a mathematician, where half proof = 0, and it is demanded for proof that every doubt becomes impossible.
~ Carl Friedrich Gauss
Joshua Cranmer
Judging from my last programming project, very few of those were common.
Indeed, this was the only one that actually bit me:
7. Comparing two objects
I recently came back from Java after a heavy dose of C#, so this was
actually very common (most^H^H^H^Hall of my comparisons were String
comparisons, too...).
Other ones that I know from experience would tend to bite people:
1. Null pointers (it helped that null was meaningful for me)
3. Preventing concurrent access to shared variables by threads
9. Mistyping the name of the method when overriding
10, 8, and 2 tend to be compile-time errors, so these mistakes probably
last all of 2 minutes on average.
4, 5, and 6 (7, too) will likely be made only be neophyte programmers or
programmers coming to Java after programming another language for a long
while.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Stefan Lotties
10. Obviously the author is irritated by the keyword 'static'.
7. Obviously the author is irritated by object comparison. Even in C
it's a difference between the comparing two char* by == and strcmp.
6.
5. The first problem some guys in my team have, too. I hate whenever I
have to check a log and see something like:
"Could not do xyz: null" and when I see the code it's just a bunch of
shit like this:
---- snip ----
try {
// lots of code...
} catch (Throwable t) {
LOGGER.error("Could not do xyz: " + t.getMessage());
}
---- /snip ----
I even found something like this once:
---- snip ----
try {
// lots of code...
} catch (Exception e) {}
---- /snip ----
Well, this happens when your boss invites programmers who barely
handle to implement whatever they had to and leave the project/company
afterwards. I guess it's time to search for such blocks again. Even
after doing this a couple of times I'm sure to find them again...
4. Wow...
2. First language, hu?
The author actually writes like java is really his first programming
language and/or he's quite a beginner. Sure we all do mistakes, but
more likely (experienced) programmers do design/architectural mistakes
and have to refactor often when it's time to implement new features.
Eric Sosman
No comment about whether these are or are not truly the
"top ten," except to note that the article makes no mention
of any kind of quantitative survey.
However, the article looks awfully old and some of its
advice is out of date. For example, error #9 (mistyping a
method name -> failure to override) says that the only way to
catch the problem is to notice that your "overriding" method
doesn't actually get called. In modern Java you'd use an
@Override annotation, and the compiler would catch the error.
(Also, examples based on AWT are just a wee bit antiquated.)
Error #6 (pass by reference or by value) has an explanation
that I think just adds to confusion. It seems to me more helpful
to say that Java *always* passes by value, but that some of those
values *are* references. Since he's just made the point about
reference values in error #7 (mixing up == and .equals), it's a
shame he didn't follow through.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Patricia Shanahan
> Additya wrote:
>> Hello friends , Here is a nice article which I have found while
>> surfing , it is about the ten common errors which may be made by any
>> Java Programmer while Programming. The article lists all those
>> mistakes and their solution.
>> http://www.ezdia.com/Top_Ten_Errors_Java_Programmers_make/Content.do?id=839
>>
>
> No comment about whether these are or are not truly the
> "top ten," except to note that the article makes no mention
> of any kind of quantitative survey.
>
> However, the article looks awfully old and some of its
> advice is out of date. For example, error #9 (mistyping a
> method name -> failure to override) says that the only way to
> catch the problem is to notice that your "overriding" method
> doesn't actually get called. In modern Java you'd use an
> @Override annotation, and the compiler would catch the error.
> (Also, examples based on AWT are just a wee bit antiquated.)
Another defense against mistyping override method names is to not type
them. I use Eclipse's source generation to produce override skeletons,
including the annotation.
Several of the errors seem to me to be biased towards learning Java as a
second language after programming only in a language with case
insensitive identifiers and 1-based arrays.
Patricia
Andrew Thompson
> Hello friends , Here is a nice article which I have found ..
(Multi-posting, spamming) liar.
Has this group become so quiet that people
will reply nicely to multi-posting spammers?
To quote from the OP's Google profile..
"IF YOU HAVE AN APPLE AND I HAVE AN APPLE
AND WE EXCHANGE APPLES THEN YOU AND I WILL
STILL EACH HAVE ONE APPLE. BUT IF YOU HAVE
AN IDEA AND I HAVE AN IDEA AND WE EXCHANGE
THESE IDEAS, THEN EACH OF US WILL HAVE TWO
IDEAS."
No, you'll *both* be clueless morons.
--
Andrew T.
John B. Matthews
<3fc52e41-c9d9-44ec...@z35g2000prh.googlegroups.co
m>,
Andrew Thompson <andrew...@gmail.com> wrote:
I vacillated over this: I detest the spamdexer's freeloading,
but I relish the review and discussion. Anyway, here's the
original article:
<http://www.javacoffeebreak.com/articles/toptenerrors.html>
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>Hello friends , Here is a nice article which I have found while
Other than errors the IDE or compiler catches, what would be my top
ten errors?
1. failing to keep comments up to date.
2. fragile initialisation that stops working if code is
renamed/reordered.
3. on global rename, renaming something that should not have been.
4. allowing Intellij to import the wrong package for a class.
5. not enough () to override precedence.
6. changing a method thinking only about one place where it is called
rather than all usages.
7. generating invalid HTML from malformed String literals (usually
involving \").
8. statics that should be instance and vice versa.
9. losing track of what each parm is for in long parm lists.
10. Not being clear about void strings, null vs "" vs " " where each
form might appear.
This is just off the top of my head. To give a proper answer I should
keep a log.
--
Roedy Green Canadian Mind Products
http://mindprod.com
The future has already happened, it just isn�t evenly distributed.
~ William Gibson (born: 1948-03-17 age: 61)
Roedy Green
<andrew...@gmail.com> wrote, quoted or indirectly quoted someone
who said :
>
>Has this group become so quiet that people
>will reply nicely to multi-posting spammers?
In movies and TV the hero and the bad guy often attempt to intimidate
each other with exaggerated politeness. Think Bond/Blofeld.
Joshua Cranmer
> 1. failing to keep comments up to date.
Yes. VERY MUCH. Oh look, here's a master comment which succinctly
describes everything I need to know. *crash* Oh wait, it's months out of
date...
It led to a very spectacular crash signature, though.
RedGrittyBrick
Roedy Green wrote:
> On Tue, 8 Dec 2009 00:14:45 -0800 (PST), Additya <addy...@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
>
>> Hello friends , Here is a nice article which I have found while
>> surfing , it is about the ten common errors which may be made by any
>> Java Programmer while Programming. The article lists all those
>> mistakes and their solution.
>> http://www.ezdia.com/Top_Ten_Errors_Java_Programmers_make/Content.do?id=839
>
> Other than errors the IDE or compiler catches, what would be my top
> ten errors?
>
> 1. failing to keep comments up to date.
Nowadays I try to avoid making comments that make work for myself. It's
a good thing to remove comments that merely restate what the code says.
These are the sorts of comments that are most likely to need maintenance
when code changes.
> 2. fragile initialisation that stops working if code is
> renamed/reordered.
I don't understand what this means.
> 3. on global rename, renaming something that should not have been.
Easy to do in text editors. I've never had this problem with IDEs that
understand language syntax.
> 4. allowing Intellij to import the wrong package for a class.
I've sometimes hit enter too quickly in the equivalent Eclipse dialogue.
> 5. not enough () to override precedence.
I overuse () because I so frequently switch languages and worry about
applying the wrong precedence rules.
> 6. changing a method thinking only about one place where it is called
> rather than all usages.
When changing an API I often create wrapper functions to preserve the
old API.
> 7. generating invalid HTML from malformed String literals (usually
> involving \").
>
> 8. statics that should be instance and vice versa.
Definitely a more subtle form of mistake.
> 9. losing track of what each parm is for in long parm lists.
Ooh yes. See JOptionPane. For my own code, I now prefer a more
factory-like approach where you use individually named method calls to
set each parameter.
>
> 10. Not being clear about void strings, null vs "" vs " " where each
> form might appear.
This is troublesome for me in many languages and DBMSs.
> This is just off the top of my head. To give a proper answer I should
> keep a log.
An interesting list.
--
RGB
Patricia Shanahan
>
> Roedy Green wrote:
>> On Tue, 8 Dec 2009 00:14:45 -0800 (PST), Additya <addy...@gmail.com>
>> wrote, quoted or indirectly quoted someone who said :
>>
>>> Hello friends , Here is a nice article which I have found while
>>> surfing , it is about the ten common errors which may be made by any
>>> Java Programmer while Programming. The article lists all those
>>> mistakes and their solution.
>>> http://www.ezdia.com/Top_Ten_Errors_Java_Programmers_make/Content.do?id=839
>>>
>>
>> Other than errors the IDE or compiler catches, what would be my top
>> ten errors?
>>
>> 1. failing to keep comments up to date.
>
> Nowadays I try to avoid making comments that make work for myself. It's
> a good thing to remove comments that merely restate what the code says.
> These are the sorts of comments that are most likely to need maintenance
> when code changes.
I agree with this except for two types of comments:
1. Interface descriptions, such as Javadoc comments. Someone who just
wants to know the preconditions and postconditions for a method should
not have to read its code, let alone the rest of the code in its class.
2. Descriptions of variables. Even if the meaning of a variable can be
deduced from the code, it is often much easier to read the code
knowing what its variables mean.
Patricia
Eric Sosman
> RedGrittyBrick wrote:
>> [...]
>> Nowadays I try to avoid making comments that make work for myself.
>> It's a good thing to remove comments that merely restate what the code
>> says. These are the sorts of comments that are most likely to need
>> maintenance when code changes.
>
> I agree with this except for two types of comments:
>
> 1. Interface descriptions, such as Javadoc comments. Someone who just
> wants to know the preconditions and postconditions for a method should
> not have to read its code, let alone the rest of the code in its class.
>
> 2. Descriptions of variables. Even if the meaning of a variable can be
> deduced from the code, it is often much easier to read the code
> knowing what its variables mean.
May I add a third type? The "why" comment for a section
of code can be important, the comment that explains (or cites)
the reason for doing something (or for not doing it).
/* Rebalance the Frammis to minimize the flimflam margin
* (algorithm P from TAOCP section 3.1.4.1.6)
*/
/* No need to synchronize here: We already hold the
* Lochinvar lock
*/
/* Make the defensive copy *after* instantiating the
* MuggleModel
*/
... and so on. There's a fairly extreme example in a piece of
my own code, where a two-line method
private static int peakUsers(int users, double frac) {
double stdev = Math.sqrt(users * frac * (1 - frac));
return (int)Math.round(users * frac + 2 * stdev);
}
... also carries a thirty-two-line comment giving the reasoning
behind the two lines. The "what" is clear from the code; the
"why" requires explanation.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Patricia Shanahan
I agree that those comments are needed, but assumed that case was
covered by not being "comments that merely restate what the code says".
I think the interface and variable explanation comments should be there
even if they contain no data that could not be deduced from a detailed
examination of the code.
Patricia
Gunter Herrmann
Patricia Shanahan wrote:
> 2. Descriptions of variables. Even if the meaning of a variable can be
> deduced from the code, it is often much easier to read the code
> knowing what its variables mean.
I prefer self documenting code as:
NOT: integer a1; // Used for counting loops
BUT: integer loopCounter;
Use variable names that are self documenting.
Best regards
Gunter
Roedy Green
<RedGrit...@spamweary.invalid> wrote, quoted or indirectly quoted
someone who said :
>> 2. fragile initialisation that stops working if code is
>> renamed/reordered.
>
>I don't understand what this means.
The simplest form of the error occurs if you write code like this:
/** dome radius in metres */
private static final double DOME_RADIUS = 50.0;
/* dome area in square meters */
private static final double DOME_AREA = Math.PI * DOME_RADIUS *
DOME_RADIUS;
Then you turn loose a code tidier on it that alphabetizes that code,
it will stop working because of the forward reference.
A more subtle form occurs if you rename variables as part of
refactoring, then tidy.
Roedy Green
someone who said :
>
>> 3. on global rename, renaming something that should not have been.
>
>Easy to do in text editors. I've never had this problem with IDEs that
>understand language syntax.
The biggest problem comes with Intellij. It has a project-wide global
rename that you can invoke by mistake when you meant to rename only
the variables or methods of a single class. I don't mean renaming
invocations of a single method. For example, it renames every init
method in the project in every class, including the ones in Applets.
Roedy Green
someone who said :
>> 9. losing track of what each parm is for in long parm lists.
>
>Ooh yes. See JOptionPane. For my own code, I now prefer a more
>factory-like approach where you use individually named method calls to
>set each parameter.
IDEs might come to the rescue here and display code as if you could
use keywords to identify parms.
Eric Sosman
> On Wed, 09 Dec 2009 09:32:05 +0000, RedGrittyBrick
> <RedGrit...@spamweary.invalid> wrote, quoted or indirectly quoted
> someone who said :
>
>>> 2. fragile initialisation that stops working if code is
>>> renamed/reordered.
>>
>> I don't understand what this means.
>
> The simplest form of the error occurs if you write code like this:
>
> /** dome radius in metres */
> private static final double DOME_RADIUS = 50.0;
>
> /* dome area in square meters */
> private static final double DOME_AREA = Math.PI * DOME_RADIUS *
> DOME_RADIUS;
>
> Then you turn loose a code tidier on it that alphabetizes that code,
> it will stop working because of the forward reference.
Fortunately, it will also stop compiling.
> A more subtle form occurs if you rename variables as part of
> refactoring, then tidy.
The obvious cure, I'd say, is "don't tidy."
There seems to be a fascination with performing silly
mechanical manipulations on source code: Alphabetizing the
identifiers, aligning all the comments at the same horizontal
position, deleting "this." except where absolutely needed,
and so on. IMHO, this sort of "tidying" is only of use when
you've inherited a truly crufty chunk of code, for example
something that's lost its indentation somewhere along the way.
One thing "tidying" does is nullify any effort the original
programmer might have made to communicate with the reader by
means of carefully-chosen arrangement and layout.
Here's the opening sentence of a well-known book, "tidied:"
age age all all authorities before before being belief
best comparison darkness degree despair direct direct
epoch epoch everything evil far foolishness for for going
going good had had heaven hope in in incredulity insisted
it it it it it it it it it it its its light like noisiest
nothing of of of of of of of of of of of of on only or
other period period present received season season short
so some spring superlative that the the the the the the the
the the the the the the the times times to us us was was
was was was was was was was was was way we we we we were
were winter wisdom worst
I humbly opine that this classic of English literature has lost
a wee bit of zing in the obsessive tidying-up.
(See also the delightful scene near the beginning of "Busman's
Honeymoon" where Bunter lays into the housekeeper who has helpfully
dusted all those dirt-encrusted bottles of ancient Port ...)
--
Eric Sosman
eso...@ieee-dot-org.invalid
Roedy Green
<notform...@earthlink.net> wrote, quoted or indirectly quoted
someone who said :
>I prefer self documenting code as:
>NOT: integer a1; // Used for counting loops
>BUT: integer loopCounter;
As a general rule, when trying to understand other people's code, I
have no problem with the details. Java is probably the easiest
language I have used for this since everything is done in such an
idiomatic way. It is the overall "What is this class for?" type
comments that I crave, the stuff too obvious to the author to bother
documenting.
Tony
> On Tue, 8 Dec 2009 00:14:45 -0800 (PST), Additya <addy...@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
>
>> Hello friends , Here is a nice article which I have found while
>> surfing , it is about the ten common errors which may be made by any
>> Java Programmer while Programming. The article lists all those
>> mistakes and their solution.
>> http://www.ezdia.com/Top_Ten_Errors_Java_Programmers_make/Content.do?id=839
>
> These might be the errors the author makes, but I doubt they are the
> errors programmers make in general. For example forgetting the arrays
> are 0-based is not likely unless your last language was FORTRAN, a
> rather rare occurrence.
Yes, I cannot agree more. Forgetting the 0-based thing would be highly
unlikely.
Tony
Joshua Cranmer
> These might be the errors the author makes, but I doubt they are the
> errors programmers make in general. For example forgetting the arrays
> are 0-based is not likely unless your last language was FORTRAN, a
> rather rare occurrence.
BASIC?
Patricia Shanahan
> On 12/08/2009 03:41 AM, Roedy Green wrote:
>> These might be the errors the author makes, but I doubt they are the
>> errors programmers make in general. For example forgetting the arrays
>> are 0-based is not likely unless your last language was FORTRAN, a
>> rather rare occurrence.
>
> BASIC?
>
Maybe. Fortran is not a plausible choice because the dimension statement
allows specification of the start index. An experienced Fortran
programmer would be alert to the possibility of an array not starting at 1.
Patricia
Wojtek
As in BASIC:
Dim Years(1999 to 2008) as Integer
Years(2002) = 5
Which is why there are two functions LBound(array) and UBound(array).
So a for loop may look like:
for yearCount = LBound(Years) to UBound(Years)
' do stuff
next
--
Wojtek :-)
alexandre...@yahoo.fr
This article contains mistakes and does *not* give good solutions.
I'll give you some but first:
Java refers to what the other refers as 'functions' as 'methods'.
10. static
Yup, Java fuxx0red big one on that. From an OO point of view the
static concept is heresy. From a unit testing point of view it's
a major pain in the arse. Second worst offender would be the
proliferation of the singleton pattern (not as bad as static but
quite scary).
"9. Mistyping the name of a method when overriding"
I'm using the @Override annotation since as far as I can remember
and IntelliJ warns me in real-time if I'm making a mistake.
Oh, btw using an "insert / implement / override method..."
and your IDE's "program by intention" features makes it less
likely to get the name of the method wrong since it's filling
it for you.
8. and 7. regarding == and equality.
Yup, Java fuxx0red again big times with hashcode and equals
being present in Object.
There's not much to do about it if you're into OO / multiple
inheritance (because you use interface to model your OO
abstractions right?):
http://www.artima.com/lejava/articles/equality.html
"3. Preventing concurrent access to shared variables by threads"
The very concept of sharing mutable "variables" [sic] by threads
is shabby at best. There are OO language who do very fine with
multi-threaded code that ain't using no shared mutable "variables".
1. NullPointerException?
OMG... Did the 90's called to tell they want their NPE back?
I'm using @NotNull since JetBrains made it available in
IntelliJ and now IntelliJ is free so there's zero reason
not to introduce some DbC into Java... From an OO point
of view the very concept of a null reference is *very*
discutable. So come on, start @NotNull'ing your entire
codebase, you won't regret it. We're doing it since
literally years (so long I can't remember).
I don't know what Eclipse/NetBeans support is for the
@NotNull annotation but anyway IntelliJ can be configured
to have these @NotNull be "transparent" for the rest of
the team (the one stuck on mediocre IDEs ;) [flame, flame,
trolling for an IDE war ;]
Seriously now... I think people that aren't littering their
codebase with @NotNull and final's should be shot (well, to
be honest everything should have been final and modifiable
refs should have been flagged 'var' or something). And
before the retarded comments "but that make the code hard
to read" I answer "collapsing IDEs you donkeys!" (or collapsing
plugins you donkeys!!!).
It's interesting to see that several of the errors in the
article are due to language defects (coming from the lack of
OO understanding from the Java creators at the time they
created Java: Gosling admitted putting interfaces in because
the concept "seemed to work" in other language and later
regretted putting the abstract keyword in and allowing
implementation inheritance, he regretted not having gone "pure
interface").
The 'static' SNAFU, the implementation SI / interface MI f*ckup,
the hascode()/equals(...) retardedness... Not very OOish IMHO.
Then it's interesting to see that two of these can be
solved by using annotations (@NotNull / @Override).
The article is not completely wrong but it's author
apparently ain't "thinking outside the box" much :(
and certainly didn't look out for better solutions
than the one he's suggesting.
That said I love Java. But boy do I know its quirks :)
Lew
>> Hello friends , Here is a nice article which I have found while
>> surfing , it is about the ten common errors which may be made by any
>> Java Programmer while Programming. The article lists all those
>> mistakes and their solution.
alexandre...@yahoo.fr wrote:
> This article contains mistakes and does *not* give good solutions.
Astounding that a spammer would spam for something not worthwhile, simply
astounding!
> I'll give you some but first:
>
> Java refers to what the other refers as 'functions' as 'methods'.
Some of still call them "functions" informally, also "routines" or
"subroutines". They definitions fit even though they be not politically
correct any more.
> 10. static
>
> Yup, Java fuxx0red big one on that. From an OO point of view the
> static concept is heresy. From a unit testing point of view it's
"Heresy" is not a concept properly applicable to engineering, because dogma is
the only heresy.
...
> 1. NullPointerException?
>
> OMG... Did the 90's called to tell they want their NPE back?
>
> I'm using @NotNull since JetBrains made it available in
> IntelliJ and now IntelliJ is free so there's zero reason
> not to introduce some DbC into Java... From an OO point
> of view the very concept of a null reference is *very*
> discutable. So come on, start @NotNull'ing your entire
> codebase, you won't regret it. We're doing it since
> literally years (so long I can't remember).
>
> I don't know what Eclipse/NetBeans support is for the
> @NotNull annotation but anyway IntelliJ can be configured
> to have these @NotNull be "transparent" for the rest of
> the team (the one stuck on mediocre IDEs ;) [flame, flame,
> trolling for an IDE war ;]
Annotations do not depend on a particular IDE but on the annotation type being
in the class path. Any Java IDE will support '@NotNull' if you give it the JAR.
> Seriously now... I think people that aren't littering their
> codebase with @NotNull and final's should be shot (well, to
> be honest everything should have been final and modifiable
> refs should have been flagged 'var' or something). And
> before the retarded comments "but that make the code hard
> to read" I answer "collapsing IDEs you donkeys!" (or collapsing
> plugins you donkeys!!!).
A pragmatic programmer will commit heresy if this is your dogma, yet still
write decent code, but they'll do it without disagreeing with you, because
dogma aside, you make an excellent point.
> It's interesting to see that several of the errors in the
> article are due to language defects (coming from the lack of
> OO understanding from the Java creators at the time they
> created Java: Gosling admitted putting interfaces in because
> the concept "seemed to work" in other language and later
> regretted putting the abstract keyword in and allowing
> implementation inheritance, he regretted not having gone "pure
> interface").
Citation, please.
> The 'static' SNAFU, the implementation SI / interface MI f*ckup,
> the hascode()/equals(...) retardedness... Not very OOish IMHO.
There's opinion, and there's truth. Nothing wrong with 'hashCode()' and
'equals()'.
> That said I love Java. But boy do I know its quirks :)
This is one thing to love about Java. Every other programming language seems
to have True Believers. Java stands alone in that pretty much everybody who
uses it bitches about it mercilessly and believes they would have done better,
and pretty much everybody uses it.
--
Lew
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>Yup, Java fuxx0red big one on that. From an OO point of view the
>static concept is heresy. From a unit testing point of view it's
>a major pain in the arse. Second worst offender would be the
>proliferation of the singleton pattern (not as bad as static but
>quite scary).
What's so bad about static?
--
Roedy Green Canadian Mind Products
http://mindprod.com
If you think it�s expensive to hire a professional to do the job, wait until you hire an amateur.
~ Red Adair (born: 1915-06-18 died: 2004-08-07 at age: 89)
Chris Riesbeck
> On Sat, 26 Dec 2009 03:40:36 -0800 (PST), alexandre...@yahoo.fr
> wrote, quoted or indirectly quoted someone who said :
>
>> Yup, Java fuxx0red big one on that. From an OO point of view the
>> static concept is heresy. From a unit testing point of view it's
>> a major pain in the arse. Second worst offender would be the
>> proliferation of the singleton pattern (not as bad as static but
>> quite scary).
>
> What's so bad about static?
Indeed. It hasn't affected my unit testing process. What's the bad
interaction?