>>>>>This is a general question of philosophy. I've received instruction from various people over the years to go one way or the other. Some have said always code for the unexpected condition. Others have said it's unexpected, should never happen, is in error and should crash. This has been in various languages.
>>>>>
>>>>>I'm curious what the consensus is from VFP experts.
>>>>>
>>>>>Suppose I have a value that should always be only 1, 2, or 3. It represents the state of something. Let's say 1=in cart, 2=ordered, 3=shipped. It should never be any other value.
>>>>>
>>>>>In your code do you code for the OTHERWISE clause?
>>>>>
>>>>>

DO CASE
>>>>>    CASE nStatus = 1
>>>>>        * It's in cart ... process it thusly
>>>>>        process_in_cart()
>>>>>
>>>>>    CASE nStatus = 2
>>>>>        * It's ordered ... process it thusly
>>>>>        process_ordered()
>>>>>
>>>>>    CASE nStatus = 3
>>>>>        * It's shipped ... process it thusly
>>>>>        process_shipped()
>>>>>
>>>>>    OTHERWISE
>>>>>        * Should never happen ...
>>>>>ENDCASE

>>>>>
>>>>>Is the OTHERWISE clause needed there? Is it only needed if there's logic below that depends on the state?
>>>>>
>>>>>And what about cases like this:
>>>>>
>>>>>

lnValue = 1   && Should only ever be 1, 2, or 3
>>>>>
>>>>>DO CASE
>>>>>    CASE lnValue = 1
>>>>>        * Process as 1
>>>>>
>>>>>    CASE lnValue = 2
>>>>>        * Process as 2
>>>>>
>>>>>    CASE lnValue = 3
>>>>>        * Process as 3
>>>>>
>>>>>    OTHERWISE
>>>>>        * Should never happen
>>>>>ENDCASE

>>>>>
>>>>>Do you need an OTHERWISE here? It's been explicitly set to a value that's known to be in the range of testing values. I always err on the side of caution. The extra OTHERWISE clause should never be hit, but if it is ... it will catch unexpected conditions. I usually put a function call in there called silentError(), which will trap through to a single handler allowing me to catch errors that should never happen, and record their code location, etc., during development, and log the same during production.
>>>>
>>>>My 3ct (inflation)
>>>>
>>>>I place the OTHERWISE statement in scenarios like this to catch any future added conditions. For example, in the future the client decides that they want the condition of "Product removed from cart (4)". The option would be caught by the Otherwise block, and I (the developer) would see that it is not being processed correctly in this portion of the code, and needs to be addressed. If left out, the product may Not be processed as Removed, and the customer may get the product anyway. Code on the side of caution. Future developers may not be as wise as you.
>>>
>>>Would a situation of future expandability not require a factory pattern? I think a case statement would not be the right implementation for this scenario.
>>
>>I agree. This is the side of caution. But when inheriting legacy code, refactoring to implement design patterns may not be an option (time and $). Wisdom tells us to design the application to anticipate expansion from the beginning. But for most VFP application, I have encountered in recent times are maintenance to legacy code. "Don't change it, just FIX it."
>
>I have very positive results from refactoring legacy applications. Although the code sometimes looks very messy, it is often easier to encapsulate and move code to appropriate places than you would anticipate. With all the dependencies and large number of variables it often looks much more complicated than the actual process requires. I have had code of several hundreds of lines boil down to just a handful of lines by relatively fast refactoring methods. The gain is almost instantenous, because while you are at it, you learn much more about the application than by simply reading and changing the existing code. It is a valid method to "Understand Code through Refactoring", so you refactor to understand what is actually happening. I know developers who tip-toe between lines of legacy code, hoping not to break anything. This is not efficient and also not much fun for the coder, and on the long term results in more cost inevitably.
>
>If the application requires substantial maintenance and needs to survive another 5 to 10 years, "just fix it" only makes things worse over time. If it is an application where you only need to touch a few little things once in a while, but no further expansion is expected and the application will become obsolete in the near future, then I agree, it would be a waste of time and money.

Here again, I agree.

I took a contract to convert several FoxPro application to use a email component other then CDO. After reviewing the apps, I discovered that the same code had been cut-and-pasted, with a few changes, all over the place. I refactored the common code to a single routine, and called it from the various places. They were very pleased, and patted me on the head. The problem occurred when I ask them if they had any other issues. They told me; "Well, ah, no. We thought it would take longer then it took you to solve. We allocated 6 months to this, and you did it in 2 months. We'll call you if we need anything else." That was a couple of years ago. Now, I wonder if I should have just taken my "time" and earned more of their "money". :) This scenario has occurred many times in my career. I tend to work myself out of a job.