>I'm an experienced dBASE/FoxPro procedural programmer still going through the object oriented learning curve and need some advice. During my DOS days I would break down a large routine into several modules to make maintenance easier. An invoice generation routine might call subroutines to get header, line item, and finishing information. I would simply define my variables in the calling routine and all subroutines automatically could access and change the values of those variables.
>
>Now I see in the Visual FoxPro world that variables can be Global, Private, or Local. My understanding of this is that Global is what used to be known as "public" variables, able to be read and modified by any routines, forms, etc., no matter where they are called. Private corresponds to "standard" variables, like the ones I would declare in a master routine and then access/change with subroutines as needed. I also understand that Local variables are modifiable IN THE LOCAL ROUTINE ONLY and can't be accessed from ANYWHERE ELSE unless explicitly passed along as parameters to a function or form.
>
>Is there a problem with using Private variables accessible from called forms, functions, objects, etc? Yes, I understand that a danger might exist where a Private variable value might be overwritten by a called function or form, maybe written months later. But wouldn't that be the realm of the called function or form developer, who should declare variables LOCAL to that procedure? I don't see much difference whether I have to declare all variables LOCAL and then use parameters like crazy in each single subroutine, or just initialize PRIVATE variables with default values and be careful in coding called forms or functions.
>
>When I scan the messages area I can't help but see that there is a tremendous knowledge resource here with some very gifted developers -- even some authors of books I've bought! Any advice or comments would be appreciated.
>

Dean,

I'd say that unless there's some reason that you can quantify, to stick with LOCAL variables whenever. Using a PRIVATE variable in one place, leaves open the possibility that a called program may accidentally change it's value. For example, back in FPD/FPW, I'd commonly use a variable named m.result to return a value from a function. If I wasn't sure to declare it as PRIVATE in the beginning of the routine, there was a good chance that it might be overwritten. I was bitten by this more than once.

Yes, there are cases where you might want to do this in a procedural language. For example, a large number of parameters being passed in a complex call situation. However, since we can pass objects in VFP, those types of situations are no where near as frequent as they once were.

One last note. You'll also note that in addition to PARAMETERS there's LPARAMETERS as well. The difference being that PARAMETERS are private, while LPARAMETERS are local.

A well designed system uses tools such as these to hide unnecessary information from the outside world. Information hiding is a very powerful tool.