The Zen of Code Reviews: i == i
Description
A screenshot of a code review interface, likely from GitHub or a similar platform, showing a snippet of JavaScript code. The code displayed is a 'for' loop with a peculiar conditional statement inside: 'if (i == i)'. This condition is a tautology, as it will always evaluate to true, making the check pointless and likely a remnant of debugging or a copy-paste error. Below the code, a comment thread highlights the absurdity. The first comment, posted '9 hours ago', dryly points out 'i == i.'. A follow-up comment from 'a minute ago' escalates the reaction with a well-known rage-quit emoticon '(╯°□°）╯︵ ┻━┻' that incorporates the flawed logic '(i == i)', signifying extreme frustration. This meme captures the quintessential code review experience where one encounters baffling code that defies logic. It’s a humorous take on the moments of disbelief and exasperation that senior developers feel when reviewing junior developers' code or even their own past mistakes, turning a simple logical flaw into a moment of shared developer comedy
Comments
19Comment deleted
I'm pretty sure 'if (i == i)' is how you implement a quantum lock. It's both true and pointless at the same time until a senior dev observes it
Nothing sparks a 40-comment review thread faster than the “NaN detector” masquerading as an always-true branch: if (i == i) { … } - simultaneously pleasing the JIT gods and triggering every linter we pay for
After 9 hours of contemplating whether it should be '<=' or '<', the reviewer finally achieved enlightenment: the real bug was in production all along, silently corrupting data for customers who coincidentally had exactly j+1 items in their cart
Nine hours between 'j == i;' and the table flip - that's the exact amount of time it takes for a senior engineer to go from 'polite code review comment' to 'questioning every life choice that led to reviewing code where someone uses j in the loop declaration but k in the condition.' The real tragedy isn't the bug itself; it's knowing this will pass CI, make it to production, and only manifest as a subtle off-by-one filtering issue that takes three weeks and a customer escalation to trace back to this exact line
for(let [i]) ensures the loop never runs - proactive zero-iteration optimization via syntax fail
if (i == i) - always true unless i is NaN - the perfect CI greenlight for teams with disabled no-self-compare and zero edge-case tests
If your filter logic is “if (i == i)”, you’ve outsourced business rules to IEEE‑754 - everything continues except NaN and the reviewer’s sanity
🤦♂️🤷♂️🤣 Comment deleted
(makes you think) Comment deleted
Check for NaN. NaN is not equal to anything, even to another Nan Comment deleted
isNaN? Nah, let's do this Comment deleted
MDN does not recommend use that Comment deleted
that == isNaN? Comment deleted
Kazakhstan the greatest county in the world, all other countries are ruled by little girls Comment deleted
are references to one's nationality supposed to be funny? nikolay nidvoray lol Comment deleted
Yes, it is funny. Especially when the joke is about ukrainians :з Comment deleted
I think second comment is meme "Random shit, go!" Comment deleted
if (Window.closed == true) { Window.Close(); } Comment deleted
Yes Number.prototype.isNaN = function() { return this == this } It looks sensible but doesnt work, because this there points at object, not NaN value. Number.isNaN uses another way of checking for NaN, but it probably uses more code to do that, so i == i is better anyway Comment deleted