4 ms·

Here's a good one - assignment inside an if: http://www.google.com/codesearch?hl=en&lr=&q=if\(\w%2B\s%2B%3D\s*\w%2B\)&sbtn=Search http://www.google.com/codesear

Here's a good one - assignment inside an if: http://www.google.com/codesearch?hl=en&lr=&q=if\(\w%2B\s%2B%3D\s*\w%2B\)&sbtn=Search http://www.google.com/codesearch?hl=en&lr=&q=if\(\w%... Not always a bug, but quite a few of these look like bugs - the first result is especially suspect!

DrJokepu 17y ago
I don't think that the first one is a bug. First, no programmer with any experience would write (variable == true) instead of (variable). Second, there are a number of lines commented out in that area so it's likely that that particular code was intended as a "temporary hack". I think the intention of the author was definitely assignment in that case, although it is expressed in a hackish, unreadable way. Seeing the previous revisions of the same file would be helpful. EDIT/TLDR: It looks like it either is intentional, or written by very unexperienced developer.
- tomerico 17y ago
  I don't see your point. It's either a bug, or an extremely bug code. (And by the way, it certainly looks like a bug in that case).
- ZitchDog 17y ago
  It is almost certainly a bug. Fact: mAutoCommit has a setter bean property. mAutoCommit looks like it can be toggled to true/false to enable automatic updating of some configuration inside the setValue(Object) method. I'm 99.9999 percent sure that the author of the code did not intend to toggle the mAutoCommit option to 'true' each time a configuration value is set. I will agree, however, that this is almost certainly written by an inexperienced developer. It's not a stretch to think that the inexperienced developer who might test a boolean with x == true might also forget an equals sign.
- thaumaturgy 17y ago
  I write "variable == true" occasionally. I must not have any experience though; I developed the habit of being very specific after dealing with quirky languages like, say, PHP. If you want to know if the first example in that list is a bug or not, all you have to do is click on it and read the linked code. (Hint: it's a bug.)
jordyhoyt 17y ago
I love this bug! It is deeply ingrained in my head that == is the right thing to use, but I still use the convention of placing the test value first (i.e. 4 == numItems) to be sure I don't ever do this.

DrJokepu 17y ago

I don't think that the first one is a bug. First, no programmer with any experience would write (variable == true) instead of (variable). Second, there are a number of lines commented out in that area so it's likely that that particular code was intended as a "temporary hack". I think the intention of the author was definitely assignment in that case, although it is expressed in a hackish, unreadable way. Seeing the previous revisions of the same file would be helpful. EDIT/TLDR: It looks like it either is intentional, or written by very unexperienced developer.

tomerico 17y ago
I don't see your point. It's either a bug, or an extremely bug code. (And by the way, it certainly looks like a bug in that case).
ZitchDog 17y ago
It is almost certainly a bug. Fact: mAutoCommit has a setter bean property. mAutoCommit looks like it can be toggled to true/false to enable automatic updating of some configuration inside the setValue(Object) method. I'm 99.9999 percent sure that the author of the code did not intend to toggle the mAutoCommit option to 'true' each time a configuration value is set. I will agree, however, that this is almost certainly written by an inexperienced developer. It's not a stretch to think that the inexperienced developer who might test a boolean with x == true might also forget an equals sign.
thaumaturgy 17y ago
I write "variable == true" occasionally. I must not have any experience though; I developed the habit of being very specific after dealing with quirky languages like, say, PHP. If you want to know if the first example in that list is a bug or not, all you have to do is click on it and read the linked code. (Hint: it's a bug.)

jordyhoyt 17y ago

I love this bug! It is deeply ingrained in my head that == is the right thing to use, but I still use the convention of placing the test value first (i.e. 4 == numItems) to be sure I don't ever do this.