switch case - to require the break statements seems strange to me

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. Doubly impractical to do so in PHP unless you have some way to
prevent said debugging code from running in production. 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.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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.

Now, for a large project that has already been written, it may be
impractical but only because it is unlikely anyone will be willing to
spend the time or money to go back and put the stuff back in...

> 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. Of course, there may be other clever solutions that aren't
popping into my head at the moment. I'm sure you could come up with
something better.

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...

> 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.

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.

> Now, for a large project that has already been written, it may be
> impractical but only because it is unlikely anyone will be willing to
> spend the time or money to go back and put the stuff back in...

If they don't want to spend the money after the fact, they probably
wouldn't want to spend the money before the fact.

> > 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?

> Of course, there may be other clever solutions that aren't
> popping into my head at the moment. I'm sure you could come up with
> something better.

I already did... don't add useless debugging code when the code is
simple, easily understand, and highly unlikely to contain a bug.

> 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.

> > 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.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

Well, I've often found the need to treat several conditions with the
same set of statements within a switch:

switch($some_number)
{
case 1:
case 2:
{
// do some shizzle
break;
}
case 3:
{
// foshizzle that nizzle
break;
}
default:
{
// dizzle everything else here
}
}

You never need a break in the last case, and you don't need a default
case if you know all the values you expect, although if you do have one,
I believe it does have to be the last statement.


Ash
www.ashleysheridan.co.uk

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?

>> 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.

>>> 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.

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

On Sep 13, 2008, at 12:12 PM, Robert Cummings wrote:

> 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.

Ah, while I had expected that my initial comments had been
misinterpreted, I can see clearly now that they have. Hopefully, the
messages the past couple of days have cleared things up.

>>>> 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.

While there is certainly a time and a place for comments which answer
the questions of 'How?' or 'What?', the most useful comments nearly
always answer the question of 'why?'.

Why?

The questions of 'How?' or 'What?' can almost always be easily
determined with an analysis of the code.

However, such an analysis does not always lead to understanding why
code was written in the way it was written and I would strongly
recommend people adopt such a comment style.

Oh, for those using SCM (Source Code Management - like subversion),
this policy applies to the checkin comments as well. Answering the
question of why a change was made is almost always far more useful
then simply stating what was changed.

> Similarly, for simplistic case statements, there's virtually no need
> for
> a block of debug code.

Unless, the block of debug code would catch a code path that should
never be executed. Then, even for the simplistic case statements, such
a block of debug code would be useful and could save a lot of time by
catching a bug that may have taken hours to otherwise track down.