#define directive purpose

Question

What is the purpose and good usage of #define directive in C#?

There are already few questions on this topic but no answer I need. They only give examples how it works. But I need deeper explanation: why does it exist and what are good ways of using it (if any).

Basically I know how to use it, but for me the usage looks odd. Let's look at example:

#define DEV

#if DEV
Console.WriteLine("Development trace log message");
#endif

For me this is completely different from using #if conditional build with project-defined conditional compilation symbols. If we use project-defined symbol, it is attached to project build configuration and we can manage code needed to build (and excluded from build) with build configuration used. So code

#if DEBUG
Console.WriteLine("Debug log message");
#endif

is fine for me. But as I said it is completely different from using #define directive because it is managable. Am I correct that 1st example can be managed only manually commenting/uncommenting #define line on every build? If yes, it is not managable, hard-to-maintain and I think this usage of #define is extreemely bad practice and sholdn't exists in the language at all.

I can imagine usage of #define/#undef inside #if statement. Something like

#if DEBUG
#if CLIENT1
#define TEST_CLIENT1
#endif
#endif

#if TEST_CLIENT1
connectionString = "Some specific test connection" //I know this is bad practice even in conditional. Only for example purpose.
#elif
//Read connection from config
#endif

#if UNITTESTS
#undef TEST_CLIENT1
#endif

#if TEST_CLIENT1
Console.WriteLine("Some message");
#endif

Sorry for so complicated example, but that is at least something I can find useful. Though I wouldn't write such code in any way =). Is there any good usage of #define?

PS: I never used #define myself for 5 years and had no will to do it, but I got a support project which has many strange defines which even named in an odd way. Those defines usually placed at the top of the file, like in my 1st example here. And I have no idea how to maintain this code.

Answer 1

I can't see any valid reason for it other than without it, the #IF statement wouldn't exist.

When you define project level precondition variables using the /define directive on the compiler all it really does is add a #DEFINE to the code.

I would argue that this makes it manageable but not in setting it manually in the code, using the /define statement.

The other usefulness is readability and scope. Project defined statements apply to the project, #DEFINE level statements only apply to one file. This helps keep things organised, readable and stops variable issues.

Answer 2

'#define' is there because people expect it to be there. :) For your purposes (e.g. a large project) it may make more sense to keep preprocessor symbols in your project. For quick debugging or other purposes #define may be the best choice. Additionally, #define allows fine-grained (file level) control of symbols.

Imagine you have a large codebase and a single module that is giving you trouble. You might wish to '#define TRACE' or '#define DEBUG' only in the single file where you want to enable tracing/debugging for performance reasons.