On Sat, 2008-09-13 at 10:09 -0400, Eric Gorr wrote: > On Sep 12, 2008, at 5:13 PM, Robert Cummings wrote: > > > On Fri, 2008-09-12 at 16:51 -0400, Eric Gorr wrote: > >> On Sep 12, 2008, at 4:27 PM, Robert Cummings wrote: > >> > >>> On Fri, 2008-09-12 at 16:11 -0400, Eric Gorr wrote: > >>>> On Sep 12, 2008, at 3:44 PM, Robert Cummings wrote: > >>>>> > >>>>> I don't see how that in any way makes an argument for or against. > >>>>> Once > >>>>> still must spend client's money wasting time on code that has > >>>>> questionable merit. Yes, some debugging code is a great boon in > >>>>> any > >>>>> application, but littered everywhere to fulfill someone's > >>>>> subjective > >>>>> philosophical ideal when sometimes it's just plain unnecessary... > >>>>> wasteful IMHO. > >>>> > >>>> As far as I know, no one has yet come up with a proof showing when > >>>> debugging code is and/or is not necessary. > >>>> > >>>> The simple fact is that bugs can popup anywhere and spending a > >>>> client's time and money by spending a few minutes writing all of > >>>> the > >>>> simple test cases throughout an application can be well worth it as > >>>> it > >>>> can save far more of the client's time and money by not wasting > >>>> it on > >>>> tracking down bugs that could have been easily caught. > >>> > >>> It is impractical to include debugging code for every conditional > >>> in a > >>> program. > >> > >> I have yet to see any evidence that it is impractical, especially > >> after one has gotten into the habit. After all, for switch > >> statements, > >> adding in a default case takes mere seconds. > > > > Yes but if you do for case, you SHOULD do for if/else if/else which is > > an analagous approach. > > > >>> Doubly impractical to do so in PHP unless you have some way to > >>> prevent said debugging code from running in production. > >> > >> It isn't hard to prevent a code path from running in a production > >> environment and allowing it to run in a development environment. Just > >> one example, in PHP, would be globally defining something like > >> PRODUCTION and then testing to see if it has a value of 1 or 0 and > >> then writing an if statement to test the value before executing some > >> code. > > > > There you go... you just ran a useless branch. Replacing one code path > > with another is hardly an optimial solution. What if your case > > statement > > is in a tight loop that runs a million times? > > How could that possibly matter since the code is never supposed to be > executed to begin with and if it is executed it would immediately > imply there is a bug? This discussion started because you said put a default statement in for debugging purposes rather than leave it empty. This suggests that you have a finite number of case statements that handle a specific set of values and that there may be values that don't need handling. Since they don't need handling the optimal path is not to have a default statement, but you suggest adding one with debugging information even though no processing need occur for some values. Now do you understand? Just because you have a switch doesn't mean all values need handling. > >> Furthermore, the whole point of these test cases is for those parts > >> of > >> the code which are never supposed to be executed to begin with, so > >> that alone will aid in preventing said debugging code from executing > >> in production...and if said debugging code does run in production, > >> would that be such a bad thing (assuming it doesn't interfere with > >> the > >> user)? After all, because it (like the default switch case) was > >> executed, it immediately implies there was a problem... > > > > If they're never supposed ot be executed then why are you adding extra > > code? That sounds like a need for better logic skills, not a need for > > debugging code. > > Because, it is never supposed to be ... not never will be. Bug's cause > all kind of things to happen...including code paths that aren't > supposed to happen. > > I doubt any client would believe it a good thing that a bug that > should have been caught in development wasn't caught until production > because mere minutes weren't spent putting in debug code that would > have caught these bugs. You're probably one of those people that comments incrementing an index *shrug*. I mean it's mere seconds to add a useless chunk of comments that may someday help someone understand you're incrementing $i. Similarly, for simplistic case statements, there's virtually no need for a block of debug code. > >>> Maybe you're > >>> confusing debugging code with unit tests. As I said earlier, it is > >>> far > >>> more practical to do so for complex conditions where a reader might > >>> easily get lost. Rather useless for simplistic cases. > >> > >> Until one finds it has saved hours because a problem was caught, I > >> can > >> understand why some would think that it is rather useless. > > > > I've spent hours on bugs before, they were never once related to not > > having put debugging fluff into a simple set of case statements. They > > were almost always related to lack of comments in a complex or hackish > > chunk of code. > > > Great. I hope that continues. I'm sure it will. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
