4 ms·
There's grey zone and there's being obtuse. We're not talking about fancy tricks here - the clearest way to retrieve the truth value of a boolean variable is t
by candybar 13y ago
There's grey zone and there's being obtuse. We're not talking about fancy tricks here - the clearest way to retrieve the truth value of a boolean variable is to refer to it directly, not comparing it for equality against a constant.
- grecy 13y agoThat might be the clearest way for you to write it today, though I'm talking about it being clear for someone else to read many years from now. As so many posts on HN have said lately; writing code is easy, it's the reading that's difficult.
- candybar 13y agoHow is if (x == true) easier to read than if (x)? Deliberate obtuseness makes things harder to read.
- grecy 13y agoRead my original comment. It would very much depend on context, and, as I said, I'd be more inclined to do it in the false case. It's funny, you still seem to think there is a "right and wrong" here, and you can't see that coding style is just like writing a poem - each individual will do things a little differently.
- candybar 13y agoWhat context does it depend on? Where is it reasonable to say (x == true) instead of x? Edit: your original post said "If I were writing something, and I really wanted to make it clear that I was testing a boolean to be true, I might write that." What does this even mean? Simply writing x isn't really really clear, so you write (x == true) to make it extra clear? if (x) is testing boolean to be true and it's crystal clear. What else can it mean?
- grecy 13y agoI personally think it depends on the complexity of the current function, and the complexity of the variable x. i.e. if x has been read and written to a bunch of times in the function already, it might add clarity to be very clear that you mean "if x is false". The clearest way I can think of to write that, that's hopefully less prone to misinterpretation is if(x == false) rather than if(!x) Like I said, these are just my personal opinion and an expression of how I code (and likely things that I find difficult or often misread when reading the code of others)