Hi,
if($a == 4){
echo 'ok';
}
Now displays an error because $a variable is not defined. my decision:
if(isset($a)){
if($a == 4){
echo 'ok';
}
}
But maybe there are better solutions?
views:
112answers:
5
+5
A:
Your solution is correct, but if you want to be 100% "clean" then you should never have to use isset(), as your variables should always be in scope. You should define $a = null at the beginning, and check if it is null.
This is how a statically typed program would work (say java). But since you are using PHP, you could decide to relax this, and play by PHP rules, by allowing use of undefined variables (which makes code more dirty, but shorter and more readable). It is up to you. In this case, change the error reporting in php.ini not to issue this kind of notices.
Palantir
2010-07-14 06:35:09
Catches the point: if you use PHP, do it the way PHP is meant to do it.
Iacopo
2010-07-14 06:52:54
Actually, isset() is still useful for use with arrays. Otherwise, I agree with you. Generally, isset() shouldn't have to be used this way. @Iacopo Just because PHP allows us to be sloppy, doesn't mean that we should be sloppy.
George Marian
2010-07-14 06:59:59
+13
A:
I think it's good enough. You could merge the two ifs if you like.
if (isset($a) && $a == 4) {
echo 'ok';
}
KennyTM
2010-07-14 06:35:47
+2
A:
Ideally, you shouldn't have to do this. If $a is originally being created inside a conditional, but not under all circumstances, you should declare it and set it to null before that conditional.
Compare:
if(false)
{
$a = 4;
}
//...
if($a == 4){
echo 'ok';
}
To:
$a = null;
if(false)
{
$a = 4;
}
//...
if($a == 4){
echo 'ok';
}
Yes, that if (false) will never set $a to 4. However, the second example will not trigger the warning.
Also, I hope you're not relying on register_globals being on.
Otherwise, if you must use isset(), I would combine the call into one if statement, as suggested by KennyTM.
George Marian
2010-07-14 06:57:24
A:
The following solutions are shorter, but ugly (i.e. the kind of code that make seasoned programmers run away in disgust):
if (@$a == 4) // Don't show the warning in this line (*UGLY*)
echo 'OK';
or
error_reporting(error_reporting() & ~E_NOTICE); // Don't show any notice at all (*EVEN UGLIER*)
Both are considered bad practise, as you could miss an unrelated notice which could be symptomatic for some deeper problem.
giraff
2010-07-14 07:07:50
Only ever use `@` for errors that are not otherwise avoidable, for example `@unserialize($mayNotBeUnserializable)`. Never get into the habit of using an `@` where an `isset` would do! Also, never hide errors (during development)! That doesn't make them go away, it just makes debugging that much harder. (Can't make that clear enough. :))
deceze
2010-07-14 07:12:18
"Both are considered bad practise" That saved you from a downvote. It's a bad idea to suggest such things to newbies.
George Marian
2010-07-14 07:23:38
@George I agree. But before long, they will some encounter sort of if "in the wild" and think to themselves: that's great, it's saving me X keystrokes. It's not a "better solution", though, if "better" refers to beauty of code.
giraff
2010-07-14 08:05:12
@giraff A fair point. I guess my suggestion would be to make the disclaimers more prominent. It's not exactly evident from your post that you're describing what **not** to do.
George Marian
2010-07-14 08:14:33
A:
@ has done so much damage to the PHP community at large. I can't count the hours gone into debugging and fixing @ty code.
battal
2010-07-14 07:42:02