When developing applications, there are times when you need to temporarily change the behavior of a working method — for example, to investigate a bug, check something quickly, or work around an issue for the moment.

We’ve all been there: you make a quick change, test it… and then accidentally ship that change in a Release build because you forgot to remove it.

One of the simplest and most reliable ways to protect yourself from this kind of mistake is to use preprocessor directives together with a compile-time error:

#if RELEASE
#error TEMPORARY TEST CODE DISABLED – REMOVE BEFORE PUBLISH
#endif

What this does

With this directive block:

  • In Debug builds, everything compiles and runs normally.
  • In Release builds, compilation fails with an error.
  • Publishing or packaging with this code is impossible until it’s gone.

Visual Studio will highlight the #error in red at compile time, making it impossible to miss.

Why this helps

It’s extremely common to add quick temporary code like:

public Result ProcessData(Input input)
{
    // temporary logic for debugging
    return Result.Success();
}

…but then forget to restore the real implementation before the next release. Traditional comments like:

// TODO: remove before publishing

often slip through the cracks — they don’t stop the build, and teams just ignore them.

Using #error forces attention. You must remove the temporary block before a Release build will succeed.

When to use this

This technique is especially useful when:

  • You need to stub or mock behavior temporarily.
  • You’re isolating hard-to-reproduce bugs.
  • You’re doing hot-fix or diagnostic injections in live environments.
  • You want to enforce a fail-fast safeguard against accidental publishing.

Unlike runtime assertions or unit tests (which validate behavior during execution or testing), this approach prevents a Release build from ever compiling until the guard is removed.

Best practice tips

  • Keep the compile-time message clear and actionable.
  • Combine this with good commit messaging (e.g., “remove this stub now that fix is confirmed”).
  • Consider using CI/CD pipelines to enforce additional checks for accidental leftover code.