To empty() or not to empty()? That is the question 2

[Dweezel]

I've recentley done 2 different tutorials on website login systems. In both cases the first section of code, after the shortened names for the form variables had been set, was a check to make sure that the two form fields (username and password) had been filled out. There were two different approaches however.

1:
if(!empty($username) && !empty($password))


2:
if($username && $password)

Is there a right and wrong way of doing this, or are these both valid techniques? In previous tutorials I've always been told to use isset() or empty() for this kind of thing.
Both 1 and 2 seem to work fine though.

 

[nawlej]

Well, there really is no right or wrong way, it just depends on your style IMHO. Im particular to negative logic for some odd reason, so my flavor would have been
!empty, but, like I said, that is just me. Code the way you want to.

___________________________________
--... ...--, Eric.

 

[nawlej]

By the way, the way that isset and empty differ is that, isset will check to see if a variable exists, and will return true even it has a null value. On the other hand, empty(), will return false if the variable is set but it is NULL. Of course, both functions will return false if the variable does not exist. It all depends on what you would like to check for.

___________________________________
--... ...--, Eric.

 

[Dweezel]

Thanks for clearing that up Eric. Cheers.

 

[sleipnir214]

In general, there is more than programming style to be considered here when considering the two comparisons.

The second one, in particular, can give you unexpected results because of PHP's automatic type casting.

If $username contains the value 0 (zero), for example, the comparison:

if($username && $password)

must convert $username to a boolean before it applies the "&&" operator. A value of zero, though not null, will convert to FALSE, so you can have a legitimate value in a variable yet your PHP code will think otherwise.


Also, a quick comment about your use of the variables $username and $password when getting values from a form. I strongly recommend that you use PHP's superglobal arrays rather than singleton variables. The singletons require that the php.ini setting "register_globals" be "on", which can be a security hole. Also, six months from now you may not remember how the variable $username got its value -- but $_POST['username'] will be immediately obvious.





Want the best answers? Ask the best questions!

TANSTAAFL!!

 

[Dweezel]

Thanks for the tip about the problem with 0 and false Sleipnir.
About the other point, I don't think I was very clear in my original post. When I wrote "after the shortened names for the form variables had been set". I meant:

$username=$HTTP_POST_VARS['username'];
$password=$HTTP_POST_VARS['password'];

Thanks for the heads up though.

 

[nawlej]

Oh yeah, while we're on that subject....If you are running an up to date PHP release, I would get in the habit of doing:

$username=$_POST['username'];
$password=$_POST['password'];

Instead of:

$username=$HTTP_POST_VARS['username'];
$password=$HTTP_POST_VARS['password'];

The reason for this is that although it is currently supported, there is talk of HTTP_POST_VARS not being suported in future releases.

___________________________________
[morse]--... ...--[/morse], Eric.

 

[Dweezel]

Thanks Eric.
It always bugs me when this kind of thing happens with web languages. The newer shortened way of using these variables is clearly easier, but I can never see the point of not supporting older methods of coding.
I'm always reading that deprecated html tags will not be supported by browsers in the future. What exactly is the point of this kind of thing? I know using css is a much better system for formatting web pages than using the 'deprecated' html tags, and I fully support it's promotion and development. But I don't see the point in making older web pages unreadable in newer web browsers.
Anyway, I'll stop there because this post doesn't really belong in this thread(or on this forum for that matter).
Thanks for your help though guys.

 

[sleipnir214]

Actually, I think the question, "Why deprecate language features?" is germane to PHP.

Basically, it's a question of quality of code.

In order for a language to continue to support every old feature while implementing new ones, the language engine must continually grow. That growth will inevitably lead to an enormous and unwieldy code base that compiles to a poorly-performing application.

Not only that, but the code necessary for support of the older features can lead to idosyncratic kludges in the code that will be hard to maintain.

Also, maintaining continuing support for the older features can actually constrain your code base to the point that it becomes impossible to add any new features.

The problem as all this applies to PHP is that the language is evolving fairly quickly -- much more quickly than publishing companies can update their books on the language. This can be especially frustrating for people learning the language, as often by the time a PHP book is bought, the language or the default configuration options have changed to the point that the example code in the book no longer works.

But it's like having a tree in your front yard -- every so often you have to prune it to maintain its health.





Want the best answers? Ask the best questions!

TANSTAAFL!!