ID:265467
 
It seems everyday, I use if statements less and less, mostly doing var?true:false or doing weirdarse formulas that people would never think of. Do any of you also do this? =/
Nope. I use if() almost all the time. I use ? for short bits, or inside embedded text strings. Like such:

"[person ? person : "None"]"


if() has the advantage of allowing you to put multiple statements after it with ease. And it has the whole readability thing.
Ol' Yeller wrote:
It seems everyday, I use if statements less and less, mostly doing var?true:false or doing weirdarse formulas that people would never think of. Do any of you also do this? =/

Well of cource you would, you're dan!
Give us some examples oh great one!
if() statements suck. Lots. I try to avoid 'em: They're ugly, they split up code, they make things difficult to debug...

Checking if something exists or not/is null with if() is nice, though.
Sometimes you hafta use them, but I personally like to write code that can handle whatever data it's given.
In response to Elation (#3)
Elation wrote:
if() statements suck. Lots. I try to avoid 'em: They're ugly, they split up code, they make things difficult to debug...

I'd like to see the practical reasoning behind this. I commonly use if, as I know that it makes code easier to read in such cases that you may need to check something and then execute multiple statements based on the evaluation.

As for splitting the code up... what? It's pretty easy to read code that branches off in such form as:
statement1
statement2
if(/*something*/)
statement3
statement4
statement5


Hiead
In response to Hiead (#4)
I agree with Hiead. Use whatever you need whenever you need it. If you need the if() proc, use it. It is not useless to me, actually really helpful. I luv my teddy bear soft if proc! :) *lol lol, jk*
In response to Lou (#5)
Large if statements can be avoided, If statments cause lag in loops and arent always the best choice.
In response to Strawgate (#6)
Strawgate wrote:
Large if statements can be avoided, If statments cause lag in loops and arent always the best choice.

A loop is an if statment, a label, and a goto statment.
var/index = 6
forloop{
dostuff()
index++
if(index >= 0){
goto forloop
}
}


The if statment is the basis for almost all higher level functions. Heck, even transistors, the building blocks of every computer chip, are basically little if statments.
In response to Strawgate (#6)
Strawgate wrote:
Large if statements can be avoided, If statments cause lag in loops and arent always the best choice.

The lag caused by if statements is pretty negligible. If you have so many iterations that having an if statement in the interior of your loop is causing noticeable lag, then the real culprit is probably your loop (or more likely, loops).
In response to Hiead (#4)
"I'd like to see the practical reasoning behind this."

I gave you some. They're ugly, and they split up procs...they make stuff so *specific*. Really not a good idea to use any more than you have to.

if() statements are like the mush that evil people feed their tortoises. Feed them too much and they get addicted, their jaws enlarge and they won't eat healthy greens.
In short: if() statements are the spawn of the devil, a corporate plot to take over the world using tendrils of evil in the form of splitting up logic and making people choose decisions and stuff.

Either that or I'm indifferent, lazy, hate making decisions and therefore write streamlined, adaptable and 'soft' code as a result.

Or something.
How would you use var?true:false type of things? I've never seen anything like that in all my short time of coding.
In response to CaptFalcon33035 (#10)
mob
var
wuss = 0
verb
be_a_man()
wuss = 1
show_off()
world << "[wuss ? I get all the girls! : I'm scared =( ]"



Compile and run that.
In response to IainPeregrine (#7)
IainPeregrine wrote:
Strawgate wrote:
Large if statements can be avoided, If statments cause lag in loops and arent always the best choice.

A loop is an if statment, a label, and a goto statment.
> var/index = 6
> forloop{
> dostuff()
> index++
> if(index >= 0){
> goto forloop
> }
> }
>


The if statment is the basis for almost all higher level functions. Heck, even transistors, the building blocks of every computer chip, are basically little if statments.

Thats not true. I use large loops with many procs that can be stopped or started, thus allowing you to stop a part of it.

I wouldnt use goto either. I would use spawn()procname()
In response to Elation (#11)
error: expected ':'
error: bad embedded expression [wuss ? I ge]

What? I've never seen any errors even similar to the second, and the only time I got the first one was when I was when a ) or } was in the middle.
In response to Elation (#9)
In short: if() statements are the spawn of the devil, a corporate plot to take over the world using tendrils of evil in the form of splitting up logic and making people choose decisions and stuff.

As already stated if statements are the basis for all flow control. Without them you can't really make much of anything.

In response to Elation (#11)
Bad Elation! Non-compiling code! =P

Fixed version:

> mob
> var
> wuss = 0
> verb
> be_a_man()
> wuss = 1
> show_off()
> world << (wuss ? "I get all the girls!" : "I'm scared =(")
>


The brackets on the last line probably aren't necessary.
In response to Crispy (#15)
Bad Cryspi, wusses don't get all them ladies!
In response to Crispy (#15)
Crispy wrote:
The brackets on the last line probably aren't necessary.

They actually are, because of the order of operations (<< has a higher precedence than ?). =P
In response to Ol' Yeller (#16)
Ol' Yeller wrote:
Bad Cryspi, wusses don't get all them ladies!

Blame Elation, not me. =P
In response to Wizkidd0123 (#17)
Wizkidd0123 wrote:
Crispy wrote:
The brackets on the last line probably aren't necessary.

They actually are, because of the order of operations (<< has a higher precedence than ?). =P

That's what I was afraid of. =/ I just couldn't be bothered testing it. =)