whats the differnce

[mforan]

quite a noobish question...

whats the differnce to these 2 if statements?

 

if (value=valuie && value=valuie)

 

if ( (value=valuie) && (value=valuie) )

 

am i right in thinking they perform the exact same operation anyway :S

[RussellReal]

you need

 

==

 

((value == value) && (value == value))

 

is called if nesting, or thats what I call it..

 

its used to GROUP conditionals together

 

for example

 

if (((value4 == value1) && (value1 == value3)) || (value2 == value4)) {

}

 

&& = and

|| = or

[mforan]

i see so if your only running one comparison then

if (value=valuie && value=valuie)

is best, since u use less chars. lol. unless of course u need to compare something else away from this comparison. is that basically the idea of that?

 

yer i know about the == lol.

[RussellReal]

its always a good idea to nest your conditionals.. if you think about it..

 

if you had a neatly organized file cabinet you'd be able to find the paper you need faster.. than if you had all the papers in a pile and you have to use extra power to look through all of the papers..

 

being neat is always looked @ by employers as well..

[mforan]

yer i guess your right in a way, easier to identifiy large if questions lmao.

thanks for anwsering anyway

 

[DamienRoche]

interesting...

 

So could you do this:

 

if(($var == true && $var2 == false) || ($var3 == true || $var4 == false)){

}

 

On a similar note, do if statements, or a lot of them, use up enough resources to warrant any kind of note?

 

...being neat...haha, yeh, I certainly wouldn't go to the extent of nesting 1 level if statements (if, and, or). Is it really looked at as best practice? Things like that just seem 'inconvenient'.

 

Saying that, I don't write my code for other people to look at. Looks like I need to step up :-)

 

Thanks.

[RussellReal]

if(($var == true && $var2 == false) || ($var3 == true || $var4 == false)){

 

}

could be turned into:

if ((($var == true) && ($var2 == false)) || (($var3 == true) || ($var4 == false))) {

 

}

 

or even:

 

if ((($var) && (!$var2)) || (($var3) || (!$var4))) {

 

}

 

second or third would be considered neater

[DamienRoche]

2nd just adds extra parantheses around the two...I like the third one.

 

so could 3 be:

 

 

if (($var && !$var2) || ($var3) || !$var4)) {

 

}

 

..? that's 8 less key strokes and highlights the broader conditions. Bare in mind,

I don't write with a fountain pen so my writing is neater. I reach for the nearest biro (convenience).

 

Thanks. I didn't know I could use !$var to check if variable is false...is that considered bad practice at all, like using $$var?

[RussellReal]

!function()

!true

 

! will flip the condition

 

its like != NOT EQUAL

 

when you have a single condition in a conditional

 

the if is waiting for a value which evaluates to TRUE

 

now, if you do !whatever it will tell the if statement to wait for any value which evaluates to false, for example.. if (!true) { } the conditional will be false since it is expecting to turn a false value into true..

 

and, writing proper is usually more keystrokes..

 

writing short hand will always save you time.. like using

 

SELECT * FROM tabName WHERE field = 'value'

 

but the PROPER syntax for that would be

 

SELECT * FROM `tabName` WHERE `field` = 'value'

 

you need to decide if being proper is worth the extra keystrokes..

[trq]

writing short hand will always save you time.. like using

 

SELECT * FROM tabName WHERE field = 'value'

 

but the PROPER syntax for that would be

 

SELECT * FROM `tabName` WHERE `field` = 'value'

 

Backticks are only mysql specific I believe so if your looking to write proper / portable sql I would not recommend using them at all.

[Mark Baker]

There's no real benefit in saving keystrokes these days, when memory and disk space are no longer critical issues.

 

 

It's probably more important to make you code readable, and often that can mean extra braces around conditions.

[RussellReal]

writing short hand will always save you time.. like using

 

SELECT * FROM tabName WHERE field = 'value'

 

but the PROPER syntax for that would be

 

SELECT * FROM `tabName` WHERE `field` = 'value'

 

Backticks are only mysql specific I believe so if your looking to write proper / portable sql I would not recommend using them at all.

 

even so, its still a good idea

 

for example

 

using spaces in table names or field names..

 

and also if you're going to move from MySQL to another SQL engine, you've seriously got hundreds of other things to change.. for example.. mysql_connect.. mysql_query

 

I'm sure you could do

 

// sql.php

$connector = "mysql_connect";

$query = "mysql_query";

$db_select = "mysql_select_db";

$escape = "mysql_real_escape_string";

 

and then use those variables as functions in your script and change those function names when your port over to a new SQL engine/program..

 

but I'm sure 98% of the people don't do that and will most likely have to go over al their code in the future anyway.. and backticks make the code look so much neater.. and makes it more flexible

[Guest]

@RussellReal Not necessarily. If someone is going to expect a change in database, they could probably prevent the need to make all those changes by simply using the PDO library, or some other database abstraction layer.

 

It may be better simply to use PDO/any abstraction layer even if no change is expected. Either would save you from the pain of changing all those mysql_* calls.

 

Regardless, having spaces in your tables/fields is bad practice; that is, if you're arguing portability either across different databases or different developers. It's better to have good habits rather than depend on things that simply work for your current needs. I haven't checked, but if I remember correctly, there are some databases that won't accept spaces in table names.

 

I wouldn't be surprised if it were an enforced standard in larger, commercial databases like MSSQL or Oracle; MySQL's standards would seem more relaxed (hence its popularity). But that's just my guess. Hard to remember the small details.

 

On top of that, and this is just a personal thing, but I think backquotes makes readability worse in a well formed query, especially if you're writing long, complex queries with multiple JOINs and/or UNIONs.

 

@Mark Baker Personally, I think saving keystrokes is for sake of readability, not memory.

 

My .02! 

 

EDIT:

I suppose there's also the case that you'd be developing a site somewhere where the database was already set up, and you couldn't change it. But I'm sure in a project where they have their own dedicated database staff, they would follow standards.

 

But, what's logical usually doesn't represent reality, haha. So I suppose then my argument is valid only when it's you doing both the database and development.