What does it mean when a conditional has only the keyword "true" for a condition?

[John Quach]

I've seen some If statements with a condition that's nothing more than the keyword true.

What does this mean?

[Jan Cumps]

That it will always execute the IF part.

Once we are able to look into the programmer's brain, we might know why it was done .

[Jesper de Jong]

You mean like this?

if (true) {
    // ...
}

It means that the body of the if-statement is always executed. It's ofcourse unnecessary to write code like that. I don't know why anyone would want to write code like that. Can you ask the people who wrote that code why they did this?

[Matthew Brown]

The only reason I've ever done that is while debugging. For distance, if you want to temporarily return half-way through a method, you can't just add a return statement because the compiler will complain about unreachable code. But you can put it in an if statement.

If I remember correctly, the reason the JLS allows this is to support a kind of conditional compilation - unlike while(true){...}, which is disallowed.

[John Jai]

Jesper de Jong wrote:I don't know why anyone would want to write code like that. Can you ask the people who wrote that code why they did this?

Probably it might be from a OCJP training guide / question

[John Quach]

Jesper de Jong wrote:You mean like this?

if (true) {
    // ...
}

It means that the body of the if-statement is always executed. It's ofcourse unnecessary to write code like that. I don't know why anyone would want to write code like that. Can you ask the people who wrote that code why they did this?

I got this from a tutorial on making java based video games. There's a text file with characters that build a game map and this code parses each char into a tile image or sprite.

So the conditional just loops if it has just the "true" statement?

private TileMap loadMap(String filename) throws IOException {

    ArrayList lines = new ArrayList();
    int width = 0;
    int height = 0;

    // read every line in the text file into the list
    BufferedReader reader = new BufferedReader(
        new FileReader(filename));
    while (true) {
        String line = reader.readLine();
        // no more lines to read
        if (line == null) {
            reader.close();
            break;
        }

        // add every line except for comments
        if (!line.startsWith("#")) {
            lines.add(line);
            width = Math.max(width, line.length());
        }
    }

    // parse the lines to create a TileEngine
    height = lines.size();
    TileMap newMap = new TileMap(width, height);
    for (int y=0; y<height; y++) {
        String line = (String)lines.get(y);
        for (int x=0; x><line.length(); x++) {
            char ch = line.charAt(x);

            // check if the char represents tile A, B, C, etc.
            int tile = ch - 'A';
            if (tile >= 0 && tile < tiles.size()) {
                newMap.setTile(x, y, (Image)tiles.get(tile));
            }

            // check if the char represents a sprite
            else if (ch == 'o') {
                addSprite(newMap, coinSprite, x, y);
            }
            else if (ch == '!') {
                addSprite(newMap, musicSprite, x, y);
            }
            else if (ch == '*') {
                addSprite(newMap, goalSprite, x, y);
            }
            else if (ch == '1') {
                addSprite(newMap, grubSprite, x, y);
            }
            else if (ch == '2') {
                addSprite(newMap, flySprite, x, y);
            }
        }
    }

    // add the player to the map
    Sprite player = (Sprite)playerSprite.clone();
    player.setX(TileMapRenderer.tilesToPixels(3));
    player.setY(0);
    newMap.setPlayer(player);

    return newMap;
}

[John Jai]

Did it compile? No statements shall follow a while(true) in a block. In the below methods, the first one compiles but not the second.

private void someMethod(){
	System.out.println("hai");
	while(true){
			
	}
}
	
public void someOtherMethod(){
	while(true){
			
	}
	System.out.println("hello");
}

[John Quach]

Yes. That excerpt from the program in the book did compile.

I got the source code from this website and I bought the book its based on.

http://www.brackeen.com/javagamebook/

I don't understand. Is it the consensus of this forum that just having a plain boolean value as a condition is bad practice? If so, why is this code written like this?

[Jan Cumps]

John Quach wrote:I've seen some If statements with a condition that's nothing more than the keyword true....

You got me there. The actual code you posted doesn't contain an if (true).

[John Jai]

while(true) is used here to loop till the input is not null. Note that a break statement is used to come out of the loop. Basically the loop condition is checked inside the loop block and not on the while condition expression.

[Jan Cumps]

John Jai wrote:while(true) is used here to loop till the input is not null. Note that a break statement is used to come out of the loop. Basically the loop condition is checked inside the loop block and not on the while condition expression.

Congratulations with your 1000th post, John.

[John Jai]

I earlier wrote: No statements shall follow a while(true) in a block....

public void someOtherMethod(){
	while(true){
			
	}
	System.out.println("hello");
}

Which is wrong - a break statement that breaks the while loop can be used to write statements after the while. So below code compiles fine.

public void someOtherMethod(){
	while(true){
		break;	
	}
	System.out.println("hello");
}

Thanks Jan

[Campbell Ritchie]

That looks a clumsy way to exit a loop. If you are reading, you can read in a while loop.
You ought to be catching the exceptions from your reader.
You ought to close the reader in a finally block, which you can find if you search this forum.
You can set a while loop to read every line, but it is syntax you would never have guessed

String line;
while ((line = reader.readLine()) != null)
{
   lines.add(line);
   // Very simplified version
}

Is that straight from the tutorial? I hope you are not paying for it

[Paul Clapham]

Campbell Ritchie wrote:You can set a while loop to read every line, but it is syntax you would never have guessed

Yes, and that's because it is a convoluted way to avoid having to write a loop which is executed "n-and-a-half times". Such loops are normal in computing, but when one just designed a language whose loop constructs don't support them properly, one tends to repress that knowledge. And hence one produces that ugly bit of code you posted, which has to be explicitly taught to every new Java programmer.

Whereas if you write it as a proper n-and-a-half loop it looks like this:

String line;
while (true);
  line = reader.readLine();
  if (line == null) {
    break;
  }
  lines.add(line);
}

Or if you still have a religious objection to the break statement, you bring in a flag to salute:

String line;
boolean finished = false;
while (! finished);
  line = reader.readLine();
  if (line == null) {
    finished = true;
  } else {
    lines.add(line);
  }
}

[Campbell Ritchie]

I prefer the use of !finished.

[Winston Gutkowski]

Paul Clapham wrote:Or if you still have a religious objection to the break statement, you bring in a flag to salute:

String line;
boolean finished = false;
while (! finished);
  ...

What about:

String line = reader.readLine();
while (line != null) {
  lines.add(line);
  line = reader.readLine();
}

?

No break statement, no flags, and no nasty while() clause.

Winston

[Paul Clapham]

Winston Gutkowski wrote:What about:

String line = reader.readLine();
while (line != null) {
  lines.add(line);
  line = reader.readLine();
}

?

No break statement, no flags, and no nasty while() clause.

Winston

You will have noticed that you have duplicate code there. Not the best idea. In this case there's only one line of code to be run before we know whether we have to do the second half of the loop, so it isn't that bad. If you had two lines, you would be having second thoughts about duplicating them, and if you had more than two, you wouldn't do it.

However, yes, I have seen that style before, in fact it's pretty much the standard in RPG code where I work.

[Unnar Björnsson]

I've done this, when testing the body of an if statement

[Winston Gutkowski]

Paul Clapham wrote:You will have noticed that you have duplicate code there. Not the best idea. In this case there's only one line of code to be run before we know whether we have to do the second half of the loop, so it isn't that bad. If you had two lines, you would be having second thoughts about duplicating them, and if you had more than two, you wouldn't do it.
However, yes, I have seen that style before, in fact it's pretty much the standard in RPG code where I work.

It's old Dijkstra style:

do the action that causes the condition(s)
while (condition(s) are not true) {
   do anything you like
   do the action that causes the condition(s)
}

If the "action that causes condition(s)" part (which, yes, is repeated) takes more than one line, you just put it in a method.

Hasn't failed me since 1979, when I first learned about it (oddly enough, as an alternative to COBOL's horrible 'READ...AT END GOTO...') .

Winston

[John Quach]

Campbell Ritchie wrote:That looks a clumsy way to exit a loop. If you are reading, you can read in a while loop.
You ought to be catching the exceptions from your reader.
You ought to close the reader in a finally block, which you can find if you search this forum.
You can set a while loop to read every line, but it is syntax you would never have guessed

String line;
while ((line = reader.readLine()) != null)
{
   lines.add(line);
   // Very simplified version
}

Is that straight from the tutorial? I hope you are not paying for it

Yes it is. And no I did not pay for it.

[Winston Gutkowski]

John Quach wrote:

Campbell Ritchie wrote:

String line;
while ((line = reader.readLine()) != null)
{
   lines.add(line);
   // Very simplified version
}

Is that straight from the tutorial? I hope you are not paying for it

Yes it is. And no I did not pay for it.

Personally, I don't see anything particularly terrible with it; although I know that some people are religiously opposed to "assignment" expressions.
I actually use it quite a lot myself, because it has the great virtue of putting everything in one place at the top of the loop, although there is also this alternative:
for (String line = reader.readLine(); line != null; line = reader.readLine()) {...

Winston