Develop Reference

Nested ifs or ands?

I'm a beginner level programmer who's just starting to work on actual projects, and I'm starting to think about things such as efficiency and if my code looks professional. I was wondering if, when trying to check multiple booleans, is it better to use nested if statements, or multiple && and || operators.
Action action = event.getAction();
Material holding = event.getItem().getType();
if((action.equals(Action.RIGHT_CLICK_AIR)||(action.equals(Action.RIGHT_CLICK_BLOCK))))
{
if((event.hasItem())&&(holding.equals(Material.COMPASS)))
{
//if the player right clicked while holding a compass
}
}
Does this look right? I tried to group the like if-statements together. Also, if there's anything else I can do to improve my formatting, please tell me! Thanks.

Welcome to the Stack Overflow community!
There is no problem with the code shared in the question. In some cases, it is better to opt for legibility so that your co-workers will be able to understand the proposed code better. But in the end, this is very subjective.
IMHO, it is easier to understand if we write all the conditions at once. So,
Action action = event.getAction();
Material holding = event.getItem().getType();
Boolean isRequiredAction = action.equals(Action.RIGHT_CLICK_AIR) || action.equals(Action.RIGHT_CLICK_BLOCK)
if (
isRequiredAction
&& event.hasItem()
&& holding.equals(Material.COMPASS)
)
{
// logic...
}
However, if you really want advice and tips on how to refactor it and best practices in a particular language, try Code Review community.

imo for a personal taste, i would put those nested conditions in a boolean variable that can explain the behavior as much as the comment you let in the block, like:
boolean isActionRightClick = action.equals(Action.RIGHT_CLICK_AIR ||action.equals(Action.RIGHT_CLICK_BLOCK);
boolean isHoldingACompass = event.hasItem() && holding.equals(Material.COMPASS);
and then
if ( isActionRightClick && isHoldingACompass ) {...}

Yes your code looks very good to me. I used to work on big projects and uses nested if statements, or multiple && and || operators which saves time. In your code efficiency can be traced at :
if((action.equals(Action.RIGHT_CLICK_AIR)||(action.equals(Action.RIGHT_CLICK_BLOCK))))
As now check only one condition in the or statement will satisfy the if condition which will save time and also shorten the code length.
You can make this code more shorter by removing unwanted parenthesis from your code. Which you must take care in future.
For more details related to efficient coding you can visit this link:
https://docs.oracle.com/cd/E80738_01/pt854pbh2/eng/pt/tpcd/task_WritingMoreEfficientCode-0749ba.html#topofpage

This is good to think about the quality/readability of your code.
Nested "if" are a good question in most of the case i think this depends of people. Some people prefer to nest it, to evaluate condition one after another. Some other prefer to not nest for not lose the track in the block.
But in most of the case be careful to not do to much if statement and try to replace it with pattern design (Easier said than done.). You can find a lot of it in java-design-patterns

I think you could make it even more shorter by using ternary operator (?:) right.
if (expression1) {
result = 1;
} else if (expression2) {
result = 2;
} else if (expression3) {
result = 3;
} else {
result = 0;
}
result = (expression1) ? 1 : (expression2) ? 2 : (expression3) ? 3 : 0;

How do I evaluate boolean expression with many arguments?

I am trying to set up a condition check for my code. However, the code has become long and complex. I need a simpler version of the code that can easily do the job.
I have tried to compare three boolean values separated by brackets such that I only compare two values.
if (
(((userState[0][0]&&userState[0][1])&&(userState[0][2]))) ||
(((userState[1][0]&&userState[1][1])&&(userState[1][2]))) ||
(((userState[2][0]&&userState[2][1])&&(userState[2][2]))) ||
(((userState[0][0]&&userState[1][0])&&(userState[2][0]))) ||
(((userState[0][1]&&userState[2][1])&&(userState[1][1]))) ||
(((userState[0][2]&&userState[2][2])&&(userState[1][2]))) ||
(((userState[0][0]&&userState[2][2])&&(userState[1][1]))) ||
(((userState[1][2]&&userState[1][1])&&(userState[2][0])))
)

You can use nested loop:
boolean result;
for (int i = 0; i < userState.length; i++) {
for (int j = 0; j < userState[i].length; j++) {
result |= userStage[i][j];
}
}

Clean code suggests to never write such code in the first place.
If at all, you could for example create small helper methods for each line, like:
private hasStateConditionXyz(boolean[][] userState) {
return userState[0][0]&&userState[0][1])&&(userState[0][2];
}
where "Xyz" would be a nice handsome name that tells the reader what the intention of that check is.
Of course, that breaks your ability to somehow loop over your array.
In other words:
if possible, see if it is possible to compute your result by looping over that array, instead of writing down such manual "patterns"
if not, consider using such named helper methods
Where, in the end, the real answer might be to step back and look at the overall problem to solve. Meaning: when you have such a complex "state machine", then it might be better to really create a state machine. Or to use some sort of "work flow" engine. Such tools allow you to express such complex (business?) rules in much more concise and readable ways.

Multiple else if conditions, end with an other "else if" or "else" when logic dictates the last "else"-part dictates only one possibility? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Sometimes you know because of the logic behind the conditions within your if, else if that your last condition check could be omitted and be written as an else instead. This way you do one less check, however it's less clear to read. What would be good coding? Would it even be more efficient because there is one less check or does the compiler optimize for these cases?
if(x<0){
//statements
}else if(x==0){
//statements
}else if(x>0){
//statements
}
Or with else
if(x<0){
//statements
}else if(x==0){
//statements
}else{
//statements
}

In Java, there is a potential problem if you include the condition on the last else if:
String whatIsX;
if (x < 0) {
// statements
whatIsX = "x is negative";
} else if (x == 0) {
// statements
whatIsX = "x is zero";
} else if (x > 0) {
// statements
whatIsX = "x is positive";
}
System.out.println(whatIsX);
This will give you an error. The reason is that the compiler thinks that it's possible whatIsX may not have been initialized, if none of the if conditions are true. We know that's impossible, since one of the if conditions must be true (assuming x can't be changed by another thread at just the wrong time!). But the language rules don't require the compiler to try to do the kind of analysis required to figure that out.
Because of this, it's best not to include the last condition. Changing the last else if (x > 0) to simply else will make the program legal.
This is a feature of Java because of its "definite assignment" rules. The code would work fine in most other languages.

In you case you have defined it is ok to leave it out as there are only 3 possibilities.
That is
x==0 or x<0 or x>0
Considered a scenario with more possibilities it cry in for a bug when the last else is open ended cause if all the if's & else if's fail it will enter the last else as it has no bounds.

It's even a bit worse than that. Some languages will not even allow an empty block. In Bash, in some cases, you can use a colon (':') for a null statement. In Python you can say 'pass'.
Let's not even consider, here, the question of mandatory bracketing for a 1-statement block.
I think clarity in code is very important, and compilers are pretty smart about optimizing conditionals.
If one could prove that an extra test is made that will always fail and it is in code that executes a billion times per second, well ... maybe then.
Otherwise, if one must leave out the else, one might put a comment to the effect that other 'elseifs' will likely be added.

In your case, comparing the last if is not ideal as if the 1st 2 if statements are not true, then the third one has to be true. So keeping just else would be fine.
the ternary operator would be my personal choice though.
(x>0) ? //statements : (x==0) ? //statements : //statements
it basically reads
if( x>0) then statements
else if(x==0) then statements
else statements
more about ternary operator or if statement here

Last approach is correct since if it's not = 0 and < 0 then it must be > 0 and no other possibilities left out.
On a side not, you can as well consider using a switch statement
int x = 3;
switch(x) {
case 1: x < 0;
//something;
break;
case 2: x == 0;
//something;
break;
case 3: x > 0;
//something;
break;
default: break;
}

Is it bad practice to use break to exit a loop in Java? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I was wondering if it is a "bad practice" to use a break statement to exit a loop instead of fulfilling the loop condition?
I do not have enough insight in Java and the JVM to know how a loop is handled, so I was wondering if I was overlooking something critical by doing so.
The focus of this question: is there a specific performance overhead?

Good lord no. Sometimes there is a possibility that something can occur in the loop that satisfies the overall requirement, without satisfying the logical loop condition. In that case, break is used, to stop you cycling around a loop pointlessly.
Example
String item;
for(int x = 0; x < 10; x++)
{
// Linear search.
if(array[x].equals("Item I am looking for"))
{
//you've found the item. Let's stop.
item = array[x];
break;
}
}
What makes more sense in this example. Continue looping to 10 every time, even after you've found it, or loop until you find the item and stop? Or to put it into real world terms; when you find your keys, do you keep looking?
Edit in response to comment
Why not set x to 11 to break the loop? It's pointless. We've got break! Unless your code is making the assumption that x is definitely larger than 10 later on (and it probably shouldn't be) then you're fine just using break.
Edit for the sake of completeness
There are definitely other ways to simulate break. For example, adding extra logic to your termination condition in your loop. Saying that it is either loop pointlessly or use break isn't fair. As pointed out, a while loop can often achieve similar functionality. For example, following the above example..
while(x < 10 && item == null)
{
if(array[x].equals("Item I am looking for"))
{
item = array[x];
}
x++;
}
Using break simply means you can achieve this functionality with a for loop. It also means you don't have to keep adding in conditions into your termination logic, whenever you want the loop to behave differently. For example.
for(int x = 0; x < 10; x++)
{
if(array[x].equals("Something that will make me want to cancel"))
{
break;
}
else if(array[x].equals("Something else that will make me want to cancel"))
{
break;
}
else if(array[x].equals("This is what I want"))
{
item = array[x];
}
}
Rather than a while loop with a termination condition that looks like this:
while(x < 10 && !array[x].equals("Something that will make me want to cancel") &&
!array[x].equals("Something else that will make me want to cancel"))

Using break, just as practically any other language feature, can be a bad practice, within a specific context, where you are clearly misusing it. But some very important idioms cannot be coded without it, or at least would result in far less readable code. In those cases, break is the way to go.
In other words, don't listen to any blanket, unqualified advice—about break or anything else. It is not once that I've seen code totally emaciated just to literally enforce a "good practice".
Regarding your concern about performance overhead, there is absolutely none. At the bytecode level there are no explicit loop constructs anyway: all flow control is implemented in terms of conditional jumps.

The JLS specifies a break is an abnormal termination of a loop. However, just because it is considered abnormal does not mean that it is not used in many different code examples, projects, products, space shuttles, etc. The JVM specification does not state either an existence or absence of a performance loss, though it is clear code execution will continue after the loop.
However, code readability can suffer with odd breaks. If you're sticking a break in a complex if statement surrounded by side effects and odd cleanup code, with possibly a multilevel break with a label(or worse, with a strange set of exit conditions one after the other), it's not going to be easy to read for anyone.
If you want to break your loop by forcing the iteration variable to be outside the iteration range, or by otherwise introducing a not-necessarily-direct way of exiting, it's less readable than break.
However, looping extra times in an empty manner is almost always bad practice as it takes extra iterations and may be unclear.

In my opinion a For loop should be used when a fixed amount of iterations will be done and they won't be stopped before every iteration has been completed. In the other case where you want to quit earlier I prefer to use a While loop. Even if you read those two little words it seems more logical. Some examples:
for (int i=0;i<10;i++) {
System.out.println(i);
}
When I read this code quickly I will know for sure it will print out 10 lines and then go on.
for (int i=0;i<10;i++) {
if (someCondition) break;
System.out.println(i);
}
This one is already less clear to me. Why would you first state you will take 10 iterations, but then inside the loop add some extra conditions to stop sooner?
I prefer the previous example written in this way (even when it's a little more verbose, but that's only with 1 line more):
int i=0;
while (i<10 && !someCondition) {
System.out.println(i);
i++;
}
Everyone who will read this code will see immediatly that there is an extra condition that might terminate the loop earlier.
Ofcourse in very small loops you can always discuss that every programmer will notice the break statement. But I can tell from my own experience that in larger loops those breaks can be overseen. (And that brings us to another topic to start splitting up code in smaller chunks)

Using break in loops can be perfectly legitimate and it can even be the only way to solve some problems.
However, it's bad reputation comes from the fact that new programmers usually abuse it, leading to confusing code, especially by using break to stop the loop in conditions that could have been written in the loop condition statement in the first place.

No, it is not a bad practice to break out of a loop when if certain desired condition is reached(like a match is found). Many times, you may want to stop iterations because you have already achieved what you want, and there is no point iterating further. But, be careful to make sure you are not accidentally missing something or breaking out when not required.
This can also add to performance improvement if you break the loop, instead of iterating over thousands of records even if the purpose of the loop is complete(i.e. may be to match required record is already done).
Example :
for (int j = 0; j < type.size(); j++) {
if (condition) {
// do stuff after which you want
break; // stop further iteration
}
}

It isn't bad practice, but it can make code less readable. One useful refactoring to work around this is to move the loop to a separate method, and then use a return statement instead of a break, for example this (example lifted from #Chris's answer):
String item;
for(int x = 0; x < 10; x++)
{
// Linear search.
if(array[x].equals("Item I am looking for"))
{
//you've found the item. Let's stop.
item = array[x];
break;
}
}
can be refactored (using extract method) to this:
public String searchForItem(String itemIamLookingFor)
{
for(int x = 0; x < 10; x++)
{
if(array[x].equals(itemIamLookingFor))
{
return array[x];
}
}
}
Which when called from the surrounding code can prove to be more readable.

There are a number of common situations for which break is the most natural way to express the algorithm. They are called "loop-and-a-half" constructs; the paradigm example is
while (true) {
item = stream.next();
if (item == EOF)
break;
process(item);
}
If you can't use break for this you have to repeat yourself instead:
item = stream.next();
while (item != EOF) {
process(item);
item = stream.next();
}
It is generally agreed that this is worse.
Similarly, for continue, there is a common pattern that looks like this:
for (item in list) {
if (ignore_p(item))
continue;
if (trivial_p(item)) {
process_trivial(item);
continue;
}
process_complicated(item);
}
This is often more readable than the alternative with chained else if, particularly when process_complicated is more than just one function call.
Further reading: Loop Exits and Structured Programming:
Reopening the Debate

If you start to do something like this, then I would say it starts to get a bit strange and you're better off moving it to a seperate method that returns a result upon the matchedCondition.
boolean matched = false;
for(int i = 0; i < 10; i++) {
for(int j = 0; j < 10; j++) {
if(matchedCondition) {
matched = true;
break;
}
}
if(matched) {
break;
}
}
To elaborate on how to clean up the above code, you can refactor, moving the code to a function that returns instead of using breaks. This is in general, better dealing with complex/messy breaks.
public boolean matches()
for(int i = 0; i < 10; i++) {
for(int j = 0; j < 10; j++) {
if(matchedCondition) {
return true;
}
}
}
return false;
}
However for something simple like my below example. By all means use break!
for(int i = 0; i < 10; i++) {
if(wereDoneHere()) { // we're done, break.
break;
}
}
And changing the conditions, in the above case i, and j's value, you would just make the code really hard to read. Also there could be a case where the upper limits (10 in the example) are variables so then it would be even harder to guess what value to set it to in order to exit the loop. You could of course just set i and j to Integer.MAX_VALUE, but I think you can see this starts to get messy very quickly. :)

No, it is not a bad practice. It is the most easiest and efficient way.

While its not bad practice to use break and there are many excellent uses for it, it should not be all you rely upon. Almost any use of a break can be written into the loop condition. Code is far more readable when real conditions are used, but in the case of a long-running or infinite loop, breaks make perfect sense. They also make sense when searching for data, as shown above.

If you know in advance where the loop will have to stop, it will probably improve code readability to state the condition in the for, while, or `do-while loop.
Otherwise, that's the exact use case for break.

break and continue breaks the readability for the reader, although it's often useful.
Not as much as "goto" concept, but almost.
Besides, if you take some new languages like Scala (inspired by Java and functional programming languages like Ocaml), you will notice that break and continue simply disappeared.
Especially in functional programming, this style of code is avoided:
Why scala doesn't support break and continue?
To sum up: break and continueare widely used in Java for an imperative style, but for any coders that used to practice functional programming, it might be.. weird.

Condition that is true and false at the same time in C or Java [duplicate]

This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What's the “condition” in C interview question?
Can something like this be done?
Code:
if(condition) {
printf("Hello")
} else {
printf("World");
}
Result: Hello World
What should be the condition to be used to make that possible ?
Please help. Thanks in advance.

No.
The else statement will only execute if the if didn't.

You can cheat to get this result in C:
#include <stdio.h>
#define else printf(" ");
int main()
{
int condition = 1;
if(condition) {
printf("Hello");
}
else {
printf("World");
}
}
Output:
Hello World

The only idea that comes into my mind is something like
if (printf("Hello") > 0)
printf("");
else
printf(" world");
but it's not the same thing, you can't execute both branches of an if/else: one of two is chosen.

The instructor is expecting you to fill in fork() as the condition. This is not general C code but Unix/POSIX code, and works by splitting the process into a parent process and child process. fork returns the child process id (a nonzero number, thus true) in the parent and 0 (false) in the child.
Another potential way to solve the problem, if you can add code elsewhere, is to write setjmp(jmp_buf) as the condition, and add a longjmp(jmp_buf, 1); after the conditional. However this seems to break the rules of the problem.

if/elses are either/ors. Either the if portion is executed or the else, but never both.

No, the statement is if ... else, not if ... and then also maybe. The condition is evaluated once, and the branch is chosen.

Its insane, but:
int test = 0;
String s = "";
switch (test) {
case 0: s += "Hello";
default: s += "World";
}
System.out.println(s);

Boolean type variables in both languages do not allow what you want to do. The whole point is that they must be one or the other.
To accomplish what you want, you probably need a custom type.
//This type allows for quantum weirdness
public class NotABool{
public boolean isTrue = false;
public boolean isFalse = false;
//Funky setMethod
void set(boolean value){
//...
}
}
NotABool nab = new NotABool();
if (NotABool.isTrue){
//Print "Hello"
}
if (NotABool.isFalse){
//Print "World"
}
Can you clarify what you're trying to accomplish?

The functionality you are describing looks more like the switch structures.
In Java, you can only switch on int and enum types, but in C, you can switch on string as well as int types.
It would look like so:
int i = 0;
switch (i) {
case 0:
System.out.print("Hello ");
case 1:
System.out.print("World!");
break;
}
The resulting output would be "Hello World!"
When i is 0, it matches the first case and executes the code until the next break; statement is found. If i was 1, it would only print out "World!".

In general, no, it's not possible. The way the if/else is translated to Java bytecode (and in either case, to machine code), one process will run exactly one of the two branches of the statement. If we didn't have if/else, we'd end up using goto to synthesize it, and that would look a lot like this:
if (condition) goto if_block;
else_block:
printf("World");
goto after_ifelse;
if_block:
printf("Hello");
after_ifelse:
As you can see, if the condition's true (even if it could somehow also be false!), the process will follow the 'if' branch and skip past the other. There's no way to get around this in a single process; any way would require changing the code of the program, or broken hardware (particularly RAM or CPU), or enough radiation to kill you. And every compiler and environment i know of treats if/else that way, though it's common to have the else case after the if (and invert the condition), which makes the (quite valid) assumption that any boolean condition that's not true is false.
Now with all that said...in C, it's semi possible, but not in the way you're thinking -- and not on every OS. On *nix systems, there's a system call usually called fork(), which allows one process to become two (thereby sidestepping the "one process will run exactly one branch" limitation).
if (fork())
printf("Hello");
else
printf("World");
But (1) this code has an inherent race condition -- both branches are now set to run, but either one could run before the other. You'd need to wait on the child process. And (2) this isn't a "condition", it's a function call. If you're not allowed to add code, then this should not be available as an answer.
Or you could do some evil macro stuff to translate the else into something else entirely. But anyone reading your code later would want to hunt you down and confiscate your keyboard, and that's if they're nice.