>>92
Macros should not take the place of constants where possible unless those constants change the compilation (for example, two versions of a game have different EXP curves). Macros are known to be far less maintainable precisely because they are not a part of the language. Debuggers do not see macros.
There's a good reason why virtually all modern languages provide either no macros or very limited macros (as is the case in .NET, for example). It's not an appeal to authority, it's the recognition that we've learned hard lessons and put those lessons toward our new machinations.
Outside of macros, however, it's generally a good idea to be able to tell whether or not a given datum is initialized. You cannot really do this with integers (because these languages have no notions of integers being objects and/or boxing/unboxing). Being able to indicate the state of a datum is very helpful in troubleshooting and there's really no reason to not design it that way. The only way you would want to design it seat-of-the-pants-esque would be because you think you're an expert programmer. It is masturbation at best and senseless folly at worst, especially on larger projects.
The idea is to save time. Not when writing the code, because code is written far less than it is read. It takes a couple extra seconds with language-supported constructs for constants and it gives you a large host of benefits.