Welcome To The Home Of The Visual FoxPro Experts  
home. signup. forum. archives. search. google. articles. downloads. faq. members. weblogs. file info. rss. print.
PROBLEMS OF CODE RELIABILITY IN MICROSOFT VISUAL FOXPRO

Problems of code reliability are discussed in many articles. In this article we take a look at some basic problems using variables in VFP.

Visibility
As in many other languages, Visual FoxPro developers are provided with mechanisms for working with variables that have different levels of accessibility and visibility. There are three ways for declaring variables of class methods and properties. Let us view each way in depth.

Public
Within the range of visibility, the visibility of a public declared variable is the widest. Any module within the application can use these variables when needed. As a rule, in such variables links to global objects and miscellaneous global parameters that characterize the whole system are kept. Such variables must be created and initialized at system’s startup and used during its work only for reading. These variables are not the safest type, because it’s hard to monitor their usage, thus having the risk that, unintended, the value, and even the type, of the variable can be changed within the system. And one of the most widespread mistakes is when you use PUBLIC variables for transferring data from one module to another. To improve code reliability, you should constantly monitor a list of such variables for usage. For example, you can define the whole list of such variables in the same module and give them names with special prefix (e.g. GV_*). Better yet is it to minimize the use of public variables.


Private
These types of variables have their own problem. They are no real variables until specifically filled with a value. Within the range of visibility this type of variable is visible within the module where it is declared and filled and can be used by any procedure, function or method called by this module. Try the following code and you get my point:

PROCEDURE ABC
PRIVATE pPrivVar1
LOCAL lcLocalVar1
?"Procedure ABC"
?"Local var:",lcLocalVar1
* neither variable is filled with a value
* from what we know, the pPrivVar1 should be seen by the XYZ procedure. 
* So I do NOT pass it as a variable
XYZ( lcLocalvar1)
return

PROCEDURE XYZ( tcSomeVar )
?"Procedure XYZ"
?"Passed var: ", tcSomeVar
?pPrivVar1 && we should be able to see it. BUT ….
Return



This is what we get when running the above code

Declaring a variable as private is a widespread practice, but isn’t the safest. Not just for the above-mentioned problem but also for the fact that any procedure, called by the procedure or function that declared the variable can change the value of that variable unintended and even change the type of the variable, thus corrupting the code in the calling procedure. To solve the problem of transferring of a set of parameters from a module to a calling procedure it is recommended to create a separate class that will contain this set of parameters as members. Imagine the situation (according to the example above):
You have already debugged code. Then you make some changes in function B, and you’ve forgotten to declare a variable X and therefore it has just been blocked by the variable transferred from procedure A. The whole system fails to work properly. Agree, not a pleasant situation. And search of similar mistakes is very labor consuming. Unfortunately Microsoft Visual FoxPro compiler doesn’t provide developers with an opportunity of controlling of all variables used in a procedure, as it does e.g. VB6 with the help of "Option Explicit".


LOCAL
As against two previous ranges LOCAL enables a variable to be visible within only given procedure, function or method. This way of declaring of variables is the safest and it’s recommended for declaring of variables used in procedures and functions instead of PRIVATE.

Try the following code:

PROCEDURE ABC
LOCAL lcLocalVar1
LcLocalVar1 = "I am ABC and named lcLocalVar1"
?"Procedure ABC"
?"Local var before calling xyz:",lcLocalVar1
* call XYZ with the lclocalvar1
* calling XYZ with the local var
XYZ( lcLocalvar1)
?"Local var after calling xyz:",lcLocalVar1
return

PROCEDURE XYZ( tcSomeVar )
LcLocalVar1 = 12345
?"Procedure XYZ"
?"Passed var: ", tcSomeVar
?"Local var 1: ",lcLocalVar1
Return

As shown in the above code, local variables can have the same name within two procedures and have a different value, and be of a different type.

Typification
VFP, as we all know, is a weak typed language. It would be very convenient to have an opportunity to specify and control the type of variables. For today, any variable, without dependence of what type it was declared can change its type during development and runtime. In objects with properties, one can, luckily, use the _assign function, using that function to control the type of the properties. But this is only restricted to objects and not to variables used in code-blocks.

Summing up
Thus, it is possible to ascertain that the current version of Microsoft Visual FoxPro compiler has two weak places in work with variables, considerably worsening reliability of a code:
1. The lack of control about the declaration and use of variables declared as PUBLIC or PRIVATE for more then one function/procedure and for LOCAL variables within the function/procedure.
2. The absence of using strict-typed variables. As is common practice in languages such as C++, C# and any .NET language.

Solution by FoxMasters
We designed +CodeInspector for solving the first problem – monitoring declaration and usage of variables. Our product is a unique tool that enables VFP developers to do this. General rule for +CodeInspector while checking code is:
Any variable from which the value is changed within a given procedure, function or module, must be declared in this procedure, function or module.
This way you are more or less forced to the usage of local variables. For convenience, except for the three ways of declaring variables mentioned above, +CodeInspector supports two more. They are:

External Array <DimensionList>
Specifies +CodeInspector, that listed arrays can be changed within the current procedure.

#ExtVar <LikeList>
Specifies +CodeInspector, that variables that satisfy listed masks, can be changed in the current procedure.

Companies, checking projects with 500,000+ lines of code use +CodeInspector for creating more solid code. Entrust the checking of your code to our product and you won’t regret it and even be happy about the results. Take your code to the next level of reliability by using FoxMasters +CodeInspector.

To learn more information about +CodeInspector, download the latest version or place an order when you visit our +CodeInspector’s homepage at http://www.foxmasters.com/codeinspector/.

ABOUT THE AUTHOR: PAVEL STASENKO

Pavel Stasenko Pavel Stasenko is the CEO of FoxMasters. FoxMasters is the author +Macros and +CodeInspector. FoxMasters is based in the Russian Federation.

FEEDBACK

BLACKLATIN99@gmail.com @ 7/13/2016 3:00:10 AM
WWW RE DOMAIN.Pedro-Gonzalez.com

MR G BLACKlatin99@Gmail.com @ 8/4/2016 10:52:35 PM
email FACEbook.com

MR GONZALEZ @ 9/27/2016 6:50:45 PM
POB 380160 BKLYN NY 11238 MR G mail out to me app operation web mail

BLACKLATIN.99@GMAIL.COM @ 12/10/2016 6:57:26 PM
MR GONZALEZ HI CALL EMAIL@BLACKLATIN99j



Your Name: 
Your Feedback: 

Spam Protection:
Enter the code shown: