This isn’t a rare case and occurs with me often and I spent countless time trying to debug the code.
Latest example, this PHP code where I used $email for the parameter and for object as well.
private function _mail( $email )
{
if( filter_var( $email, FILTER_VALIDATE_EMAIL ) ):
$email = new Zend_Mail();
$email->setSubject( $this->request->post('subject') )
->setBodyHtml( $this->request->post('message') )
->setFrom( $this->request->post('from') )
->addTo( $email )
->send();
unset($email);
endif;
}
It was throwing an error, strtr() expects parameter 1 to be an string object given and it was really frustrating to browse through zend libraries to see what obscure string statement was throwing this error.
How to avoid such mistakes?
8
One good aspect of modern programming languages is that you can have large variable names. In Object oriented programming, which you are utilising, Java conventions are quite popular.
So it would be better to have a descriptive name for the Zend_Mail object, such as
$zendMail = new Zend_Mail();
In the beginning it will consume a bit more time until the brain shifts making it a habit, but that time will have a huge return of investment and stress from having to debug similar cases.
2
I think that you have two different concept here. You have the email address of a recipient and an email message that will be sent to the recipient. So why not :
private function _mail( $recipient )
{
if( filter_var( $recipient, FILTER_VALIDATE_EMAIL ) ):
$mail = new Zend_Mail();
$mail->setSubject( $this->request->post('subject') )
->setBodyHtml( $this->request->post('message') )
->setFrom( $this->request->post('from') )
->addTo( $recipient )
->send();
endif;
}
This isn’t a rare case and occurs with me often and I spent countless time trying to debug the code.
Just that much tells me two things:
-
If it hurts, stop doing it. You say that this problem “occurs with me often,” which means that you need to make a greater effort to avoid this kind of problem. Don’t try to use two variables with the same name, ever, even when you’re sure that it’ll work. There are two possibilities: a) you’re right and it works, but your code is a lot more difficult to understand than it should be; or b) you’re wrong and, well, you’ve seen what happens when you’re wrong.
-
Learn from experience. If you keep writing the same kind of bug, you should by now be pretty darn good at recognizing the symptoms and finding the problem. Knowing that you have a propensity for creating a certain class of bug, you should constantly be on the lookout for indications that you’ve done it yet again. Use assertions to check that a variable contains the type of data that you expect. Question your assumptions. Write some unit tests to test individual components.
In PHP I prefix function/method paramaters with ‘in’ – and don’t use any variable starting with ‘in’ within the body. It’s not ideal, but it works.
Dimitris point about more descriptive names is also helpful.
My IDE does that for me.
Eclipse has “templates” for code-autocomplete (STRG+Space)
I told my Eclipse to always add a prefix to method parameters.
For example your method:
private function _mail( $recipient )
would automatically be auto-completed with $pRecipient.
Short Rule:
Always prefix method parameters, to avoid variable clashes inside the method body.
sidenote: think about using interfaces instead ob objects as method parameters.
1