My favourite "bug"
Posted on 27/2/07 by Felix Geisendörfer
Hey folks,
here comes an example of my favorite "bug" that drives me insane on occasion:
{
// Do Something
}
It just got me again and caused me to debug Model::hasField, finally implementing my own version of it until I realized what an idiot I am ... ; ). What's your favourite?
-- Felix Geisendörfer aka the_undefined
Did you like this blog post? If so, please consider subscribing to the Blog RSS feed.
You can skip to the end and add a comment.
Favourite? dunno that, but this one happened today...
.bluetableheader { backround-color: #something; }
why the hell it's not blue....[after 'bout 1,5hrs i found the typo, next time i trust firebug if its displaying an empty class definition...] :(
Hopefully a red table header will not be required...
Yep, have to say the ol' spelling mistake is my usual culprit. Either that or not using the right case.
function doSomething() {
....
}
$this->dosomething(); // Argh why won't it work??!!
/me slaps felix with a large trout
ps: guilty too of searching in my code for way too long when an obvious mistake like a typo has been made :-)
Ha! Sorry bud.
My worst is:
if ($variable = 'crap'){
echo 'you moron.';
}
catch it?
Have to agree with Ben - if ($variable = ‘crap’) - is the worst for me, because it's valid in other languages (I spend a lot of time with procedural SQL).
~GreyCells
Another evidence for the evilness of the superflousness semicolons.
s/superflousness/superfluous/
David: Naw, I really don't like that brace style, and besides that it wouldn't keep you from placing a semicolon there anyway ; ).
Dieterbe: Typos get me really seldom. The first thing I do with some new code that fails is to double click on the first instance of all variables and copy them over all other instances of it. So if that variable had a typo, at least all of them are going to have it after that. If this fixes problem then I double check the spelling and usually am done ; ).
Chris: The typo-defense mechanism from above works really well for the wrong case too ; ).
Ben: Hm that one get's me really seldom. My client project has coding standards that tell you to do:
if ('crap' == $var)
{
}
Which eliminates those errors. But this one happens to me maybe once every 3-6 month, so I don't need it for my own stuff. However, I'm blessed to only work with languages that accept '==' to compare things ; ).
Markus Bertheau: Hm I like the look and feel of it ; ). At least I've worked with VB in the past which doesn't use a semicolon to end lines and I'm pretty sure it's not a better language then PHP is ; ).
I'm always using (constant == variable) comparation pattern, but sometimes it's confusing my coworkers. They don't like this new safe way and prefer old unsafe (variable == constant) notation.
Also, some people (including CakePHP authors!) write opening curly brace at the new line. Sometimes misleading and always space consuming habit.
It's hard to persuade people to change their habits...
Andrej: That's just what I've been talking about in the comment above. However I don't like the (literal == variable) pattern because to me it it's against the way I'm thinking. My mind deals with an unknown variable $x and it needs to compare it. So it writes down $x == 'and then what to compare it to'. It doesn't make much sense to write down a string literal without having thought about what it relates to so it's an unnatural habit to me. I can see the benefits, no question about it, but they are not good enough to make me change this habit (besides when client work requires it).
Same goes for curly braces style: Yeah, things would consume more space if you put the curly brace on the same line as the condition, function declaration or whatever. But to me this is just less readable. I really need considerably longer to understand a piece of undocumented code using this syntax vs. the other one. Especially with things like 'else' it get's ugly. So again, I like my coding style and *yes* it is insanely difficult to convince people to change their habits ; ).
Not really a bug but the crazy depth of plugin directories!
~/www/mysite/app/plugins/myplugin/views/elements/myelement.thtml
*phew*
Something that gets me every now and then is when I'm developing a function to be used (like inside a CakePHP component):
function myFunction()
{
// Bunch of complex code
$result = ($this->variable !== false);
}
Then somewhere I do:
$result = $this->Component->myFunction();
if ($result == true)
{
echo 'IT WORKED';
}
And then start wondering what the heck is going on? IT SHOULD work.
It doesn't happen that often but when it does, it happens 100 times the same day :)
A couple more:
$text = '';
$text .= 'First part.';
$text .= 'Second part.';
$text = 'Third part.';
$text .= 'Fourth part';
And you go WHERE is the first part of the text? (Look at third part)
The other one: mixing up $haystack and $needle on strpos, since eventhough I use Eclipse PDT I barely take note of the tooltips.
yeah curly brace on the first line
curly brace on first line for the lose. new lines ftw.
if (condition)
{
//do stuff
}
else
{
//do other stuff
}
lets hear it for readability :D
So, my favorite is a usual "bug" on misunderstanding the type of return-types. I regulary going crazy with methods, that return on a success an object (not bool!), but on a failure a FALSE (a bool!), instead of NULL.
F.e. the different "Model::find.."-implementations on cake.
This post is too old. We do not allow comments here anymore in order to fight spam. If you have real feedback or questions for the post, please contact us.
That's why the opening curly brace belongs on the first line. :)