Question: My code base has a lot of `#if DEBUG/#endif` statements that mostly have assertion type logic that I'm not brave enough to run in production.

```
[Conditional("DEBUG")]
public void CheckFontSizeMath()
{
  //This check must not block SellSnakeOil() in production, even if it fails.
  if(perferredSize+increment!=increment+preferredSize)
    throw new WeAreInAnUnexpectedParallelUniverseException();
}

```

Will I regret changing all these over to the new way of doing things?

**UPDATE**: I'm looking for the difference between characteristics of two similar but different syntax styles for doing Assertions. I understand there is a world of other ways to do demonstrate applications work, and I do those, too. I'm not ready to give up Assertions altogether.

Also I updated the method name for a realistic debug-release-only scenario.

Answer: 
Write tests! Then you don't have to be afraid that your code is doing something that you don't expect when you start making these changes.

Once you get your code under test you can refactor to your heart's content.

Code without tests, even written yesterday, is legacy code...
Get a copy of [Working Effectively with Legacy Code](http://tinyurl.com/3yyv57m), it's an amazing book for managing legacy code; 32 reviews with 5 stars.
Other options that you have is to either use Code Contracts as suggested by Hans or to use the assertion methods in the `System.Diagnostics.Debug` namespace, e.g. 

```
Debug.Assert(1 + 1 == 2, "Math went wrong!");

```

This check is automatically removed when building the Release version.