Other languages, like Java, do not use lazy evaluation. (See what I mean about platform?)
[/quote]
What you are describing is most commonly called "short circuit evaluation". The term "lazy evaluation" is more often used in functional languages to mean expressions which are evaluated as late as possible, even allowing potentially infinite expressions to be described, so long as you are careful never to try and fully evaluate it. A classic example is a list of Fibonacci numbers, the expression is lazy such that a particular element can be evaluated, but you shouldn't try to do something like get the length of this list.
Java does use short-circuit evaluation on the operators &&, ||. According to the table in this article, all the mainstream languages that offer operators like &&, || do short-circuit evaluation on them.
This is a common idiom in Java (and most such languages), that avoids accessing an invalid object:
if(object != null && object.someCondition())
{
// ...
}
I need advice on breaking a bad habit; 'if' & while reliance' (C++)
JoeCooper's advice is good. I just wanted to point out the following:
Crickey! I was 99% sure I looked it up and I've written a few apps assuming it didn't work that way. I've got code like
Everywhere.
Must've been cause I got the term wrong. Thanks for the note about that!
if(object != null)
if(...)
{
...
};Everywhere.
Must've been cause I got the term wrong. Thanks for the note about that!
all the mainstream languages that offer operators like &&, || do short-circuit evaluation on them.
Assuming that they aren't overloaded anyways. In C++ if you overload && or || then short circuit evaluation no longer applies. Some languages don't allow operator overloading on logical and and logical or for this reason.
There is something to look out for though if you feel like you're being too reliant on conditional statements. Make sure your code is separated into neat routines that only address a single task and Don't Repeat Yourself (aka the dry principal). So, if you have massive routines with lines and lines of code with many many branches of possible execution you are quite probably violating the DRY principal and should refactor. It makes your code more readable and maintainable and all that jazz and even more performant a lot of times as you likely won't need as many clock cycles to get through your various branches to execute the code you need to. All the above advice is good. This is just an important aside.
Assuming that they aren't overloaded anyways.
[/quote]
I would hope not, not for such operators anyway! Good catch though.
I'll dig around and try to find a good example, off the top of my head though (and where the concern lies) is I'm essentially checking the state of various entities within my game with rather large search criteria (i.e if( bool==true && x<y && y.x>x &&... ) in order to work with boolean values, which again will lead to the likes of if( coll== true ). It makes it hard for me to build values that are relevant.
I think you're probably not using functions enough.
I don't too often write if statements that compound that many checks together, but that doesn't mean my code isn't checking for all the same things yours is. My code is just structured more like this:
void main()
{
if (someBool == true)
{
Func1();
}
}
void Fun1()
{
if (someThing.x > x && someThing.y > y)
{
Func2();
}
else
{
Func3();
}
}
Just try to write small functions which perform individual tasks. A function should be in charge of doing only one thing, and should usually be small (it should fit entirely on your screen).
This is a common idiom in Java (and most such languages), that avoids accessing an invalid object:
if(object != null && object.someCondition())
{
// ...
}
Interesting factoid from the google talk. To avoid this situation, you should return a null object rather than a null reference to avoid having to do this check. Not sure on the performance impact of this as I have literally just heard it in the google talk, but it seems like solid advice to me.
Author
I have to say guys, this is honestly some of the most informative and helpful advice I've read since I started programming. Seriously, you've given me much to think about and put a lot of ideas to rest. I'll start to think in functions to make my code more approachable. As for optimizing, I'll keep brush that worry aside XD
Cheers everyone, I'll be coming back to this thread often to make sure my code doesn't disagree with the guidelines you've collectively written.
Cheers everyone, I'll be coming back to this thread often to make sure my code doesn't disagree with the guidelines you've collectively written.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
