3 ms·

Why stop there? To really get the point across, you may want to do: if (((((a == true) == true) == true) == true) == true) That way, you can be even more cer

Why stop there? To really get the point across, you may want to do: if (((((a == true) == true) == true) == true) == true) That way, you can be even more certain!

grecy 13y ago
Potentially, I can construct an independent statement to adequately convey my innervation to your statement of factual basis, that while being grammatically correct, purposefully adds needless complexity to the original statement of intent I am adequately attempting to convey. Should I?
- candybar 13y ago
  What are you talking about? If it's somehow clearer to say if (x == true) instead of if (x), why isn't it also clearer to say if ((x == true) == true) instead of merely if (x == true)? And so on?
  - grecy 13y ago
    Huh. You sound just like me 5-10 years ago, everything black and white. There is a grey zone in the middle, move in there.
    - 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 ago
        That 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 ago
        How is if (x == true) easier to read than if (x)? Deliberate obtuseness makes things harder to read.
        grecy 13y ago
        Read 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 ago
        What 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 ago
        I 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)
volaski 13y ago
People have different preferences when it comes to coding styles. There are some that are subjective (balance between clarity vs. simplicity), and there are idiotic styles such as !Boolean.FALSE.equals(aBoolean), or if (((((a == true) == true) == true) == true) == true).
- candybar 13y ago
  The point is that using (a == true) instead of a is idiotic. Now, there are good semantic reasons to use (a == true) in some languages, but we're not talking about that, we're talking purely about style. It's no different from doing (a && true) or (i + 0) or (f * 1.0) when a, i and f would suffice. Not only is it longer, it forces you to stop and think, was there a good reason why this was being done? Can a hold truthy values that the programmer's trying to exclude? Otherwise, it's a sign of a programmer that doesn't know what he's doing - I've spent a decent amount of time teaching and grading and you see this a lot in first-year school assignments, rarely in high-quality production code. In almost all cases, it's a holdover from someone going in their head "if a is true" (because "if a" doesn't read well in human languages) and writing that out, not some kind of conscious effort to make the code more readable.
  - grecy 13y ago
    > In almost all cases, it's a holdover from someone going in their head "if a is true" (because "if a" doesn't read well in human languages) and writing that out, It's interesting you admit that people are doing it "the long way" because that's how it naturally flows out of their head. Doesn't it make sense that it would naturally flow into their head the same way? What's the goal here - write very tight, concise code that fits some arbitrary standard of "correct"? Or to write code that flows out of and into people's heads easily?
    - candybar 13y ago
      I was describing first-year students who are reading code as though it's written in a foreign language, not anyone with some degree of competence. For obvious reasons, professionals should not be internally verbalizing as they write or read code, any more than a fluent French speaker should be internally translating from English as they speak French.

Why stop there? To really get the point across, you may want to do: if (((((a == true) == true) == true) == true) == true) That way, you can be even more certain!

grecy 13y ago

Potentially, I can construct an independent statement to adequately convey my innervation to your statement of factual basis, that while being grammatically correct, purposefully adds needless complexity to the original statement of intent I am adequately attempting to convey. Should I?

candybar 13y ago
What are you talking about? If it's somehow clearer to say if (x == true) instead of if (x), why isn't it also clearer to say if ((x == true) == true) instead of merely if (x == true)? And so on?
- grecy 13y ago
  Huh. You sound just like me 5-10 years ago, everything black and white. There is a grey zone in the middle, move in there.
  - 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 ago
      That 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 ago
        How is if (x == true) easier to read than if (x)? Deliberate obtuseness makes things harder to read.
        grecy 13y ago
        Read 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 ago
        What 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 ago
        I 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)

volaski 13y ago

People have different preferences when it comes to coding styles. There are some that are subjective (balance between clarity vs. simplicity), and there are idiotic styles such as !Boolean.FALSE.equals(aBoolean), or if (((((a == true) == true) == true) == true) == true).

candybar 13y ago
The point is that using (a == true) instead of a is idiotic. Now, there are good semantic reasons to use (a == true) in some languages, but we're not talking about that, we're talking purely about style. It's no different from doing (a && true) or (i + 0) or (f * 1.0) when a, i and f would suffice. Not only is it longer, it forces you to stop and think, was there a good reason why this was being done? Can a hold truthy values that the programmer's trying to exclude? Otherwise, it's a sign of a programmer that doesn't know what he's doing - I've spent a decent amount of time teaching and grading and you see this a lot in first-year school assignments, rarely in high-quality production code. In almost all cases, it's a holdover from someone going in their head "if a is true" (because "if a" doesn't read well in human languages) and writing that out, not some kind of conscious effort to make the code more readable.
- grecy 13y ago
  > In almost all cases, it's a holdover from someone going in their head "if a is true" (because "if a" doesn't read well in human languages) and writing that out, It's interesting you admit that people are doing it "the long way" because that's how it naturally flows out of their head. Doesn't it make sense that it would naturally flow into their head the same way? What's the goal here - write very tight, concise code that fits some arbitrary standard of "correct"? Or to write code that flows out of and into people's heads easily?
  - candybar 13y ago
    I was describing first-year students who are reading code as though it's written in a foreign language, not anyone with some degree of competence. For obvious reasons, professionals should not be internally verbalizing as they write or read code, any more than a fluent French speaker should be internally translating from English as they speak French.