I have migrated this topic since it makes more sense to have the discussion here.

Tim@Visual Micro wrote on Apr 25^th, 2013 at 12:16pm:

uChip wrote on Apr 25^th, 2013 at 6:15pm:


If I understand you correctly, I think this situation is a little different.  An if statement conditional has visible code that I may want to debug.  A function name does not.  From a programmer view the function name is just a marker for the beginning of the function.  There is no functional difference between before and after.

Another way to say this is that the if statement conditional is divisible and therefore before or after makes a difference.  The function name is not really divisible and therefore before or after should be equivalent.

If there has been discussion on this point it was probably around thinking that placing the breakpoint at the beginning would make it outside the function (prior to the function) and therefore not be hit when the function is called.

I would disagree with such thinking since I would regard the function name as part of the function.  As stated in my previous post I think that intuitively I would click on the function name if that were my interest and expect the break to occur immediately upon the function being called prior to any function code being executed.

I can see the other point of view, but believe that the intuitive solution is the one where clicking on the function name does what I want.

Again, a clear marker -between- statements would make it clearer where the breakpoint really is.  It is all Microsoft's fault. 

- Chip

Ok, I'm not THE expert but here are my thoughts after playing with the debugger for a little while.

I believe variable modification helps strengthen the argument for breaking before the conditional is evaluated in an if statement.  My thinking is as follows.  Presume I am investigating the code focused on the if conditional.  I click on that statement as the focus of my investigation. At the breakpoint I examine the inputs to the conditional and perhaps modify them to experiment with their impact on the evaluation.  This all works naturally if the break is at the beginning of the if.  After validating the inputs I would then step (second break in VMDB) to see that the computer and I agree on the outcome of the evaluation.

I think all would agree that the behaviors should be natural and intuitive.  The problem is that intuitive is really just our expectations which are heavily influenced by our prior experience.  I am used to debuggers that effectively replace the selected statement with a break, and only process the statement if the break is continued.  I would be interested to hear the argument of why it would be more intuitive to break after the statement to see I can map my thinking to that.

I think that the simpler case would also make your point.  If a new user wants to examine the assignment where would they set the breakpoint?  They would be focused on the assignment statement and would therefore be likely to click there.  The break would hit, but suppose the user examines "a" or wants to modify it.  If the break is before the statement then "a" would be the prior value (for discussion I'm assuming this is inside of Loop() ) at the time of the break which would be misleading for subsequent code.  If break is before and the user attempted to modify "a" their assignment would immediately be overwritten when they continued.

The reason I step back from the conditional break is that a new user is less likely to employ a conditional break.  Also, if the break doesn't hit (or hits on wrong values), I think the immediate fall-back would be to remove or simplify the conditional.  This simpler case would work and lead to what the debugger was really doing.

Note that just as in the "if" example either breakpoint behavior can be made to serve.  The user just has to know what the behavior is so they can set the breakpoint appropriately.

I spent some time trying to think of other examples to 1) see if there was a statistical preference for before or after and 2) see if there were any cases where useful behavior could not be implemented.  Here are the additional cases I thought about.  I'm sure you've thought about even more cases having had to implement them all.

   - Do {   -> like function name - before and after are equivalent
   - } While (...)   -> like "if" this favors break before if you credit my earlier argument
   - While (...) {   -> like "if"
   - For (...;...;...) {   -> like "if"
   - Switch (...) {   -> like "if"
   - Case   -> like function name, I think, but thinking about the Case value as an expression makes it like an "if"
   - }   -> like function name except when preceded by return(...); and then it's very confusing regardless of break before or after.

So one interpretation would be that statements that alter code flow generally favor break before (again, if you agree with my earlier argument).  Of course, expressions and assignments occur more frequently than code flow changes.

Another interpretation is that I could find no case where I could not achieve the break I wanted as long as I know if the break is before or after.  Does that mean this is much ado about nothing? 

I think that language and documentation can help the experience be more intuitive.  We can speak of setting a breakpoint on a statement to examine its outcome (implicit after), or its inputs (implicit before).

I'm not sure I examined enough cases but it seems logical that it is true that there is no unreachable code using either break before or break after.  I am therefore left with consistency (with the host environment) as the only argument in favor of break before.  For those who use only Visual Micro in VS to get access to the debugger a consistency argument would have no weight.  For anyone who intends to switch back and forth between Visual Micro and desktop VS debuggers, difference in behavior is a pain-point to be avoided.

Interesting to contemplate.  Thanks for the opportunity to think and discuss the topic!