A Poetic Threat Against Redundant Boolean Comparisons
Description
This image is a screenshot of a tweet from the user Alter Eagle (@AlterEagle_en). The tweet employs the classic 'Roses are red, Violets are blue' poetry format to express a strong opinion on a common coding practice. The full text reads: 'Roses are red / Violets are blue / I'll fucking kill you if / You write "== true"'. The humor is hyperbolic, channeling the intense frustration many experienced developers feel when encountering redundant code. The specific target, `== true`, refers to the practice of explicitly comparing a boolean variable against `true` in a conditional statement (e.g., `if (isReady == true)`), which is unnecessary as the variable itself can be used directly (`if (isReady)`). This is often seen as a sign of a junior developer and is a frequent point of contention in code reviews, making the exaggerated threat a relatable in-joke for those who prioritize code conciseness and best practices
Comments
38Comment deleted
Writing `if (user.isAdmin() == true)` isn't just redundant; it's a cry for help. It tells me you don't trust your own booleans to be themselves in a safe environment
Nothing shatters the illusion of our zero-trust architecture faster than spotting `isAuthenticated == true`; apparently the only perimeter we still rely on is my blood pressure during code review
After 15 years of code reviews, you realize the real technical debt isn't the legacy COBOL system - it's the junior who keeps writing 'if (isValid == true)' despite three refactoring sprints and a company-wide linting rule that somehow they've disabled locally
The '== true' check is the programming equivalent of saying 'yes equals yes' - it's not just redundant, it's a cry for help from someone who doesn't trust their own boolean expressions. Any senior engineer who's survived enough code reviews knows that seeing 'if (isValid == true)' triggers the same visceral reaction as finding 'catch (Exception e) {}' in production code - it's technically legal, but morally reprehensible. The real tragedy is that this antipattern often appears alongside its evil twin 'if (condition == false)' instead of the elegant '!condition', creating a codebase that reads like it was written by someone who learned programming from a lawyer's contract
==true saves one keystroke today, spawns a week of 'why is this falsy?' postmortem tomorrow
Nothing says we don’t run linters like if (flag == true); the CPU’s branch predictor won’t notice, but every senior on the PR will
Career progression: junior writes if(flag == true), senior changes it to if(flag), architect asks why flag is a VARCHAR that sometimes says "true"
потому что надо писать === true Comment deleted
вот джаваскриптеров раслодилось) Comment deleted
это в похапе, у жсеров хотя бы тс есть Comment deleted
Please use English as a main language in this chat — add a translation to your message if needed. too lazy to translate Comment deleted
because you should write === true Please use English as a main language in this chat — add a translation to your message if needed. Comment deleted
В Котлине если boolean? (nullable), то "== true" весьма полезно. In Kotlin, if "Boolean?" (nullable) is used, "== true" is very useful Comment deleted
+ Comment deleted
Please use English as a main language in this chat — add a translation to your message if needed. same Comment deleted
Ok,added translated message Comment deleted
same in python, although None resolves to False, so ==False would make more sense (if you're checking for falseness) Comment deleted
+ Comment deleted
need to write "=^.^= true" Comment deleted
had to write 'value === true' in js just to make sure the arg was a boolean Comment deleted
"!= false" Comment deleted
In response to most counter-arguments: If you have a nullable boolean value where null has a different meaning, you probably shouldn't use bool there, from a proper code standpoint. Maybe an enum instead В ответ на большую часть контр-аргументов: если у вас есть опциональный bool, где null значит что-то нетривиальное, скорее всего, в плане качественного кода, вам лучше юзать не bool, а какой-нибудь enum. Даже энумы на две или одну величину бывают, опускать их или заменять на булы - зачастую костыль Comment deleted
Disagree, null is the neutral value Comment deleted
When you're going for performance - perhaps. Buf, for one, you can always change to use it later, and doing so from the beginning is premature optimization. And, second, if your goal is high performance in terms of small details, you are already forced to use some low-level language like c or c++ to make it worth it - otherwise the benefit pales in comparison to the added extraneous memory operations, which take overwhelmingly longer. And if you're using those languages, a boolean null would be exactly the same as false - 0. To make them different, you'd have to pass it be pointer, and then you're deliberately adding an extra memory operation, which is never beneficial. And if we're not talking about trying to gain the best performance, then anenum is generally a much more scalable solution. In general, to check if you're doing the correct thing, ask yourself if it's in essence what you want. A boolean is a yes or no, excluding any other options. If you want something else alongside it - can't you imagine deciding to add yet another option? And then the null approach would become tricky and inflexible. Null is indeed convenient, but so are most other bad practices. If you want to write good code that will be pleasant to work with in the long term, you should be ready to sacrifice some present convenience for greater future benefits Comment deleted
We're talking about a JVM language. Comment deleted
Then it's pointless to care about such minor performance differences. You're already having to deal with excessive memory usage, which takes several magnitudes longer. So going for quality is pretty much your only option. Other than development speed, perhaps, but I really disrespect that one, so I won't consider it Comment deleted
I think a nullable boolean perfectly conveys the idea of true, false or neither Comment deleted
But what do you mean "neither". Are you absolutely sure in the general case that there's only one other option? There could, for example, be a need for different values for "implicitly undefined" and "explicitly ignored", which makes four already. So, once again, despite a nullable boolean looking more appealing, an enum is generally a better choice Comment deleted
There is no such value. Comment deleted
What do you mean? If you're writing good code, then the question isn't if there's need for it now, but whether there is even a slightest possibily for such a need arising in the future. So arguing that you definitely won't need it in your specific case defeats the purpose of adapting to as wide assortment of cases as possible Comment deleted
There is ABSOLUTELY no need for it now or ever. Comment deleted
I've already given an example of when there is - say, it's a value for a flag from an ini settings file. Then, along with the obvious true and false, it could be specified with no or invalid value, or just omitted entirely, which might require different handling. You're being too narrow-minded - good code should cover even hard to imagine situations, as long as you have a slightest suspicion that it could be possible in whatever theoretical context. Your arguments reveal that you don't get the essence of this Comment deleted
My code absolutely could not ever be used in such a situation in any way whatsoever, it doesn't make conceptual sense. Comment deleted
@devs_chat Comment deleted
well, c++ does have std::optional Comment deleted
Which is essetially a struct of bool success and T value. And is the optimizer doesn't pass it through registers, it will cause an extra memory operation Comment deleted
it wil pass it thru registers in any sane cc Comment deleted
if(your_mom.isFat) return gotem Comment deleted