Alex Rivera | Logout

Is it a bad idea to put development shortcuts in #if DEBUG blocks?

Asked 2010-07-14T20:35:17.983
13

In a few places in our code we use #if DEBUG blocks to simplify development. Things like:

#if DEBUG
   serverIP = localhost;
#else
   serverIP = GetSetting()
#endif

or

private bool isLicensed()

#if DEBUG
   return true;
#endif

return CheckSetting()

There are also a few places where we make cosmetic changes like this:

#if DEBUG
   background = humorousImage.jpg
#else
   background = standardColor
#endif

Is it dangerous to depend on #if debug to make development easier? If it is, what is a valid use of #if debug?

c# debugging
Edit
Report

2 Answers

9

Ideally, I think you would move these settings to configuration files and keep the #IF Debug directives for testing, logging, and additional "debugging" tasks. Also, keep in mind that customer facing code that you ever needed to provide a "debug" build for would now behave entirely different. My two cents.

answered 2010-07-14T20:36:33.500
0

My current style is to have a file called aadebug.h which contains a bunch of conditional defines, each of which may be preceded by // to deactivate it. The file starts:

//#define DX_DEBUG
#ifdef DX_DEBUG
#define DX_SKIP_LOGIN
// #define DX_ALLOW_BULK_USER_CREATE
#define DX_CREATE_EXCESS_LOGS
// #define DX_RANDOM_PROBE_FAILURES
#define SHORT_KEY_TIMEOUT
// #define DX_OMIT_NET_VIEWER
...
#endif

If DEBUG is enabled, the main-screen display code will show "NOT FOR PRODUCTION USE". All debug-only options may be disabled by turning off DX_DEBUG, but most options are generally controlled using individual flags. If I decide an option has outlived its usefulness, I'll remove its #ifdef's from the source and then remove the commented-out #define from aadebug.h, but otherwise I use the commented-out #define's to keep track of which #ifdef flags still exist.

answered 2010-07-14T21:15:53.470

Your Answer