ID:265467
![]() Aug 9 2005, 8:14 pm
|
|
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? =/
|
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. |
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 Hiead |
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*
|
Large if statements can be avoided, If statments cause lag in loops and arent always the best choice.
|
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 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. |
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). |
"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.
|
mob Compile and run that. |
IainPeregrine wrote:
Strawgate wrote: > var/index = 6 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() |
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 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. |
Bad Elation! Non-compiling code! =P
Fixed version: > mob The brackets on the last line probably aren't necessary. |
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 |
if() has the advantage of allowing you to put multiple statements after it with ease. And it has the whole readability thing.