You know that pattern where basic string operations like atoi get reinvented in the form of a switch statement? Yeah, "fix" it by replacing every conditional with ?:. Bonus points for automating this process!

If dto.Order.IsNotNothing() And dto.OrderId.IsNotNothing() And dto.Order > 0 And dto.OrderId > 0 Then
''do stuff
End If

Note that 'Order' and 'OrderId' are of type Integer
IsNotNothing is a .net extension method that wraps around the single line of code:
Return obj IsNot Nothing
They literally created a function so as to not need to put a space between IsNot and Nothing... ???
And the ultimate best part, Order will only ever be the values 0 or 1!

History lesson:
The ? : operator(s) comes from Algol 60, which one could use 'if' then' 'else' in the same way (inside an expression. One could say:
a := if b < c then d else e;
While needless use of the ?: operator(s) is a crime in and of itself, it has some uses, and might even be a bit easier to read than the Algol-60 version.

I will care. But every language is different, so a blanket statement can't really be made about them that'd apply to all languages.

And while everyone thinks they have "their own style", I tend to side with Douglas Crockford on this issue. There is ultimately a correct way of writing a method with white-space/parenthesis/etc. in a given language based on the syntax of that language. Deviations from the "correct" spacing/parenthesis/etc. may not have an adverse effect on the programs performance or its ability to compile, but those variation can (and often do) detract from the readability of the program by other developers (or perhaps by you in 6mo?).

These are the least-important types of errors if you ask just about anyone in the industry, but given enough entropy and layered-on bug fixes, it can become a massive problem. This isn't to say that parenthesis in a return statement are the end of the world, but they're a symptom of a larger problem that is often ignored or not recognized as a problem until it's too late.

I think you missed the point. It has nothing to do with performing a single Boolean operation in a function; it has everything to with with not just returning the result of the conditional. There is no need to do the return true/false. Just return the result of the test.

Style is an argument that is pointless to make, because there will never be one camp. Are you the type that would also argue over whether line indents should be multiples of 3 or of 4 characters?

I'm also the guy who places parenthesis around every macro #define. Because the first time you debug a problem that turned out to be because of macro expansion in an expression causing an "precedence of operators" should be the last time you ever fall victim to that problem.

And there should be a special circle of hell for people who always put parens in their return statements, even constants like return(0). IT'S NOT A FUNCTION YOU BLOODY MORONS STOP WRITING IT LIKE ONE.

Funny, I feel the same way about putting parentheses around the expression in an if or while statement. Sure those are because a language designer got tired of saving keystrokes after defining = to be assignment and == to be comparison. Just because the language designer forgot to make redundant parentheses mandatory in a return statement is no excuse for programmers to be inconsistent in coding style.

(Even though I'm inconsistent in coding style since I don't put redundant parentheses in return statements, that doesn't mean I have an excuse.)

I'm also the guy who places parenthesis around every macro #define. Because the first time you debug a problem that turned out to be because of macro expansion in an expression causing an "precedence of operators" should be the last time you ever fall victim to that problem.

Should be, but won't be. You see, some Linux driver developer decided he/she didn't need parentheses around a few macro #defines, but got lucky because the macros weren't actually used anywhere. I posted it to the linux-scsi mailing list a few years ago, and no one cared. No matter how many times you or I debug problems caused by precedence of operators in macro expansions, we should not expect any of them to be the last time.

Becasue I've been bitten in the past assigning the result of the function to a flag and having somebody else in another part of the program use flag === true and the code fail (or JSON encoding an object and seeing a string instead of the bool they expected)

Nothing WTF about the first example. It's perhaps silly, but not a WTF. As others have pointed out, it's more readable (to some) and easier to debug. The second is clearly a WTF, but the general concept is not.

However, the REAL WTF here is the complete and utter lack of null checking when doing boolean expressions like in the second example with nested object/function dereferencing. It make the result NOT boolean, but rather true, false or NPE.

I agree with GWO on this, I don't see a problem with the function existing ( hasFeatures() ), this approach is used a lot in game programming (isAlive(), isEnemy(), isVisible(), etc). The issue is that the function could have been written in one line/simplified greatly. The use of a ternary operator is also nice.