PDA

View Full Version : The ? in the code - what does it do?




zcarter
Mar 23, 2008, 09:29 PM
Hey guys..Im learning SQLite and I came across this feature.

self.author = (str) ? [NSString stringWithUTF8String:str] : @"";

I understand its taking the current string from the SQL and putting it into the defined string self.author using UTF8String formatting (becauses its stored in the SQL that way)...

So..what does the '?' in that have to do with it?

Thanks!

- Zac



lee1210
Mar 23, 2008, 09:34 PM
It's a ternary if. It evaluates the operand on the left of the ? operator. If it evaluates to true, the expression will evaluate to the value of the operand on the left of the :. If it evaluates to false, the expression will evaluate to the value on the right of the :. In this case, if str is not null, the string from the utf string pointed to by str will be returned. Otherwise an empty string will be returned.

zcarter
Mar 23, 2008, 09:41 PM
Thank you sir. Man, I should have known better =-p I learned that in CS140 lol

lee1210
Mar 23, 2008, 09:53 PM
No problem. I'd probably say this is by far the lesser used alternative. It is more concise than:
if(str != NULL) { //For god's sake, be explicit about it. True/false, not 0/non-0
self.author = [NSString stringWithUTF8String:str];
} else {
self.author = @"";
}

I wouldn't say either is more clear. Some people thing the ternary if is awful, and try to forbid it in their project/organization/etc. Some think it's the right way to do things like this. It's a matter of taste and style. The real risk is that upon immediate inspection most will instantly know what's going on with the if/else, and some might take pause with the ternary if.

pilotError
Mar 24, 2008, 07:55 AM
I wouldn't say either is more clear. Some people thing the ternary if is awful, and try to forbid it in their project/organization/etc. Some think it's the right way to do things like this. It's a matter of taste and style. The real risk is that upon immediate inspection most will instantly know what's going on with the if/else, and some might take pause with the ternary if.

I call it job security. You would be shocked how many people don't know how to use ternary operators.

gnasher729
Mar 24, 2008, 09:34 AM
No problem. I'd probably say this is by far the lesser used alternative. It is more concise than:
if(str != NULL) { //For god's sake, be explicit about it. True/false, not 0/non-0
self.author = [NSString stringWithUTF8String:str];
} else {
self.author = @"";
}

I wouldn't say either is more clear. Some people thing the ternary if is awful, and try to forbid it in their project/organization/etc. Some think it's the right way to do things like this. It's a matter of taste and style. The real risk is that upon immediate inspection most will instantly know what's going on with the if/else, and some might take pause with the ternary if.

When I started my career, my then boss, who also did a bit of programming, complained that my style was too terse. He claimed that one screenful of his code was much easier to understand than one screenful of my code. I said yes, that was true, but one screenful of my code did more than six screenfuls of his code, and that one screenful of my code was much easier to understand than six screens of his code. If you are setting not only "author", but a dozen other things as well, then a dozen if/else statements are harder to read and check for mistakes than a dozen ternary operators.

I agree with the comparison "str != NULL" though; Java got that right by only allowing boolean expressions in an if statement (or ternary operator).

I minor point: If "author" is not a class member but a property, then the if/else can lead to a lot of duplicated object code.

lee1210
Mar 24, 2008, 02:08 PM
When I started my career, my then boss, who also did a bit of programming, complained that my style was too terse. He claimed that one screenful of his code was much easier to understand than one screenful of my code. I said yes, that was true, but one screenful of my code did more than six screenfuls of his code, and that one screenful of my code was much easier to understand than six screens of his code. If you are setting not only "author", but a dozen other things as well, then a dozen if/else statements are harder to read and check for mistakes than a dozen ternary operators.

I agree with the comparison "str != NULL" though; Java got that right by only allowing boolean expressions in an if statement (or ternary operator).

I minor point: If "author" is not a class member but a property, then the if/else can lead to a lot of duplicated object code.

People can program poorly with any (or without any, really) style. There's a definite trade-off between being terse and being more explicit. Hopefully if there are fewer lines there's a smaller chance of making an error, and when done properly it should be as readable as more explicit code. With more explicit code it's more likely that "anyone" will be able to read it, but there's more room for error, and if "anyone" is going through your code they may be more likely to introduce bugs no matter what style you use.

The only time brevity is truly costly to understanding is when a programmer tries to use obscure or confusing syntax to save a line or two of code. Just because you can put a whole C program on one line doesn't mean you should.

yeroen
Mar 24, 2008, 02:54 PM
just wait until you have to track down a bug involving the comma operator

kainjow
Mar 24, 2008, 02:59 PM
Sometimes I use this, but it depends on the situation. However I almost always use parentheses and check for nil/NULL explicitly since I think it's easier to read. For example:

self.author = (str != NULL ? [NSString stringWithUTF8String:str] : @"");

SqueegyX
Mar 24, 2008, 03:14 PM
I agree with the comparison "str != NULL" though; Java got that right by only allowing boolean expressions in an if statement (or ternary operator).

Ruby does it best, IMHO. The only objects treated as false are "false" and "nil", every other value is true. It keeps code lean when checking variables have been initialized. You can still do "some_var.nil?" or "some_vale == false" if you want to get explicit about it.