I hate this convention to put literals on the left hand side of the comparison. Every time I stumble upon code like this my brains stalls for an instant trying to make sense of the expression. It just looks ugly and wrong in my opinion.
It's also mostly useless because your compiler should warn you about your first construct (and tell you to add a layer of parens if that's what you really want to do).
I realize I'm being a bit irrational with this whole thing but for some reason code like this drives me nuts (that and people not putting space around arithmetical operators and such: int a=2*4+foo(1,2,3)).
I do a ton of code reviews, often as part of an interview process, less often, for embedded developers. Conditionals written with literal lvalues is something of which I tend to take note. You're right, it's not natural, and it's less readable, but there's usually a reason why people do it: experience. If you often work in weakly typed languages, or those which allow for weird coercion in conditional statements, it's sadly often easier to form a habit which guarantees fewer bugs than it is to say "I'll always type the boolean equality/strict equality operator."
"But why don't you use better languages, then?" Because in many cases (low-level resource-constrained systems programming), it's much, much easier to deal with these weird gotchas than to attempt to get exotic  languages such as Python, Ruby, Java, and sometimes even C++ (heap? who needs a heap??), to work. Even in cases where you're able to get these languages to work easily, you're just forcing yourself to become intimately familiar with the internals of some language with which you'll ultimately wind up wrestling . Normally the point of such languages is to abstract away the system. This is the exact opposite of what you need in these environments.
"But it annoys me when people use literal lvalues where they don't need to." Ah, but this is the rub of forming a habit.
1: I'm mostly sarcastic in my use of the word "exotic" here. Don't go crazy, now. ;-)
2: Though to totally contradict myself, I will say that both Rust and Go look very, very interesting here.