if (false)

When facing a difficult bug, it's common to comment out or even delete seemingly irrelevant code. While this is a great approach, it adds cognitive load to reviews, which increases the risk of mistakes.

As an alternative, I use what I call the if (false) pattern, where I surround code that I want to suppress with an impossible conditional. The key here is that this change will be stopped by my linter, but ignored by my compiler. This means I can run the code just fine, but I can never accidentally merge it.

Some examples

Skip over code with if (false):

line1()
line2()
line3()

line1()
if (false) {
  line2() // <--- This line will no longer run
}
line3()

Return early to skip a function's implementation:

function calculateTheThing(): number {
  return someComplexThing() + someOtherComplexThing() / more()
}

function calculateTheThing(): number {
  return 5 // <--- The rest of the function is ignored

  return someComplexThing() + someOtherComplexThing() / more()
}

Forcing a conditional to be true by adding true || ...:

conditional

true || conditional

Forcing a conditional to be false by adding false && ...:

conditional

false && conditional

Prevent a component from rendering in React with { false && ... }:

<>
  <SkipMe />
  <KeepMe />
</>

<>
  { false && <SkipMe /> }
  <KeepMe />
</>

Conclusion

There is no harm in introducing unnecessary conditionals as long as your CI system is set up to detect them. Lean into this in order to experiment with your code while developing more easily and safely.

This post was written while I was still largely coding manually, but I've found this pattern to be useful when developing with agents as well. Agents will happily delete code in order to run an experiment, and long context windows or separate sessions can easily cause these temporary experiments to accidentally become permanent. Instructing the agent to use this pattern helps protect you from that.