Contact Us

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:

if (!$this->hasField($field));
    // 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


You can skip to the end and add a comment.

David said on Feb 27, 2007:

That's why the opening curly brace belongs on the first line. :)

Tom said on Feb 27, 2007:

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...] :(

wioota said on Feb 27, 2007:

Hopefully a red table header will not be required...

Chris  said on Feb 27, 2007:

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??!!

Dieter@be said on Feb 27, 2007:

/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 :-)

Ben Hirsch said on Feb 28, 2007:

Ha! Sorry bud.

My worst is:

if ($variable = 'crap'){
echo 'you moron.';


catch it?

GreyCells  said on Feb 28, 2007:

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).


Markus Bertheau said on Feb 28, 2007:

Another evidence for the evilness of the superflousness semicolons.

Markus Bertheau said on Feb 28, 2007:


Felix Geisendörfer said on Feb 28, 2007:

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 ; ).

Andrej  said on Feb 28, 2007:

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...

Felix Geisendörfer said on Mar 01, 2007:

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 ; ).

zeen  said on Mar 01, 2007:

Not really a bug but the crazy depth of plugin directories!



Mariano Iglesias said on Mar 02, 2007:

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 :)

Mariano Iglesias said on Mar 02, 2007:

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.

rob  said on Mar 08, 2007:

yeah curly brace on the first line

jim  said on Mar 14, 2007:

curly brace on first line for the lose. new lines ftw.

if (condition)

//do stuff




//do other stuff


lets hear it for readability :D

Rastullah said on May 21, 2007:

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.