The Question Mark: In-Line If Statements

While working on bigger projects during my internship, I came across multiple uses of a question mark symbol “?” in the code. I did some research and learnt that they are essentially used for in-line if statements. I now use them with some regularity, so I thought I’d share what I have learnt with you, fellow developer.

We’ve all been in the situation where we have code in the style of the following:

 if(x < 5)  
      return true;  
      return false;  

This works, but it is a lot of lines for little work. What we can do is shrink it down into one line by combining the “?” and the “:” symbols to create an in-line if statement. The ? symbolises the end of the if statement, as it would in regular speech. The : symbolises the difference between the right or “true” answer and the wrong or “false” answer. For example, in the statement “If x is less than five then true otherwise false” the ? is the “then” and the : is the otherwise. This comes across in code like so:

 return x < 5 ? true : false;  

This also means you can turn multiple “if-else”s into one statement. Say you had:

if(colour == Color.Blue)
     return 1;
else if(health == 10)
     return 2;
else if(name == "Foo")
     return 3;
     return 4;

You could instead use the following:

 return colour == Color.Blue ? 1 : (health == 10 ? 2 : (name == "Foo" ? 3 : 4));  

It just simplifies the whole process of using if statements. Also very useful for checking if a variable has already been initialised and initialising it if it hasn’t like so:

 playerCircleGhost = null != playerCircle ? playerCircle : new Circle();

I have started using this a lot while coding, so I hope it proves useful to you!



4 thoughts on “The Question Mark: In-Line If Statements

Add yours

  1. It’s good to use ternary statements, in the right place they can be useful. But you first example if still confusing.

    What’s up with simply having:

    return (x < 5);

    Much clearer and less code.

    1. Ah that it also nice and clean, and not something I had realised you could use! I suppose it’s better to use ternary statements to avoid the null declarations like in the second example. I think I’ll be using your example in the future as well 😀

  2. Hmm. I must admit I’m not a huge fan of compressing statements like this. They make the code much smaller, but this size reduction isn’t really reflected in any particular performance gain, it just makes the code a bit harder to understand and virtually impossible to debug. I like being able to step through decisions and watch what is going on, rather than finding the code zooming off in a particular direction with a value that I can’t easily unpick.

    When I write code I’m usually working to make it as easy to understand as possible. Unless you are really up against the wall performance-wise (and that is hardly ever the case) then I’d advise to you think about doing the same.

  3. I think this is also what Jake was referring to; when there is something complex the it makes more sense to detail how it’s working in more lines so that it is clear, but I’ve had a few instances recently where it has just been dependant on a boolean or greater/less than that I need one of two resources and there it has seemed much easier use these statements so that in one line it’s clear what is happening as opposed to several in an if statement. Such as “int EnemiesMissing = respawnEnemies == true ? MaxEnemies – LiveEnemies : 0;” can be understood in one line as opposed to 3 or 5 lines, and is marginally quicker to type out 🙂 I appreciate the necessity for both at certain points though

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Powered by

Up ↑

%d bloggers like this: