#if DEBUG vs. Conditional("DEBUG")

Which is better to use, and why, on a large project:

#if DEBUG
public void SetPrivateValue(int value)
{ ... }
#endif

or

[System.Diagnostics.Conditional("DEBUG")]
public void SetPrivateValue(int value)
{ ... }

Well, it's worth noting that they don't mean the same thing at all.

If the DEBUG symbol isn't defined, then in the first case the `SetPrivateValue` itself won't be called... whereas in the second case it will exist, but any *callers* who are compiled without the DEBUG symbol will have those calls omitted.

If the code and all its callers are in the same assembly this difference is *less* important - but it means that in the first case you *also* need to have `#if DEBUG` around the *calling* code as well.

Personally I'd recommend the second approach - but you do need to keep the difference between them clear in your head.

With the first example, `SetPrivateValue` won't exist in the build if `DEBUG` is not defined, with the second example, **calls** to `SetPrivateValue` won't exist in the build if `DEBUG` is not defined.

With the first example, you'll have to wrap any calls to `SetPrivateValue` with `#if DEBUG` as well.

With the second example, the calls to `SetPrivateValue` will be omitted, but be aware that `SetPrivateValue` itself will still be compiled. This is useful if you're building a library, so an application referencing your library can still use your function (if the condition is met).

If you want to omit the calls and save the space of the callee, you could use a combination of the two techniques:

[System.Diagnostics.Conditional("DEBUG")]
public void SetPrivateValue(int value){
#if DEBUG
// method body here
#endif
}

Let's presume your code also had an `#else` statement which defined a null stub function, addressing one of Jon Skeet's points. There's a second important distinction between the two.

Suppose the `#if DEBUG` or `Conditional` function exists in a DLL which is referenced by your main project executable. Using the `#if`, the evaluation of the conditional will be performed with regard to the library's compilation settings. Using the `Conditional` attribute, the evaluation of the conditional will be performed with regard to the compilation settings of the invoker.

I'm sure plenty will disagree with me, but having spent time as a build guy constantly hearing "But it works on my machine!", I take the standpoint that you should pretty much never use either. If you really need something for testing and debugging, figure out a way to make that testability seperate from the actual production code.

Abstract the scenarios with mocking in unit tests, make one off versions of things for one off scenarios you want to test, but don't put tests for debug into the code for binaries which you test and write for production release. These debug tests just hide possible bugs from devs so they aren't found until later in the process.

This one can be useful as well:

if (Debugger.IsAttached)
{
...
}