See also BinaryChop. 

Regardless of the method (macros, inline code, or QueryMethod''''''s), an AbstractionChop is a technique for separating conditional logic from the associated code blocks, allowing you to test if TheProblem is in the conditions themselves, or in the code blocks.

----

In some environments, I've created macros that let me replace complicated conditionals with known good (syntactically) template equivalents, but leaving the inside of the blocks unchanged. For example:

Replace:

 /* pre-example */
 if (a really complicated expression)
   {
   /* some code */
   }
 else
   {
   /* some more code */
   }
 /* post-example */

with: 

 /* pre-example */
 if (testA)
   {
   /* some code */
   }
 else
   {
   /* some more code */
   }
 /* post-example */

Playing games like this helps to discover whether problems are in the conditional logic or inside the blocks.

-- TomStambaugh
----
I use a very similar (but apparently simpler) approach.  Given Tom's first example code, I might temporarily rewrite it as:

 /* pre-example */
 if (   true ||    a really complicated expression)
   {
   /* some code */
   }
 else
   {
   /* some more code */
   }
 /* post-example */

If I wanted the else clause to execute, of course I'd use "if( false && ...".  This kind of stuff works best if you have really fast turn around times. -- CurtisBartley

If compiling is a problem, using an online debugger set the program counter to the appropriate block when stepping through, thus sidestepping the conditional expression. If your conditional expression has side effects, you will naturally have to manually recreate the side effects. Check first that you aren't inlining too aggressively.

----
Tom's approach sounds like KentBeck's QueryMethod done with 
macros. The advantage of QueryMethod really comes out if 
you follow a test-driven approach. --KielHodges

You can use QueryMethod in C++ and Java. I don't see where creating your own control structures comes in. A QueryMethod is essentially a method which returns a boolean for use in other control structures; it's not, say, a method which accepts a block and executes it conditionally somehow. -- DaveHarris

----

A vaguely related coding trick I've sometimes used in C/C++ is...

  static bool bFlag = false;   // set 'true' in debugger
  if (bFlag)
     // interesting stuff here...

Then I can "comment/uncomment" code during runtime
''(even in "fascist" development frameworks ;-)''
by setting a breakpoint and changing the static value by hand.
-- JeffGrigg

----

Microsoft's Visual C++ has that pattern in its memory allocator. There's a variable called _crtBreakAlloc, and a counter called _lRequestCurr which is incremented on every call to malloc(). When the two are equal, the allocator breaks into the debugger. You have to use the debugger to set the value of crtBreakAlloc you want it to break on. -- DaveHarris

----
I encountered a case where I made enough memory allocations to cause _lRequestCurr to wrap around to -1; since _crtBreakAlloc is -1 by default my program halted (it was running in the debugger at the time). So if you see an odd debug break at 

  if (lRequest_ == _crtBreakAlloc)
      _CrtDebugBreak();
then this could be why.

----
CategoryAbstraction