Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Naming conventions again........
Message
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00258085
Message ID:
00258629
Views:
14
Hi Joe,

Well, I did say coding standards rather than naming conventions, so if you don't mind the whole ball of wax, here goes...

1. When creating PRGs, if the progam/class method returns a value via the RETURN command it is typed as a FUNCTION. Otherwise it is typed as a PROCEDURE.

Note: This is a hangover from my days working in Pascal. Procedure cannot directly return a value there as they can in FoxPro.

2. The exit from any procedure/function/method always occurs at the last line of the procedure/function/method.

3. No prematuring exits from iteration structures is permitted unless a significant gain in performance is required.

Note: I've been working in Fox since 1987. Not once in 12 years have I ever used the EXIT command. The same is true of LOOP. I personally consider these to be the equivalent of BASIC's GOTO.

4. All mathematical/logical operators are preceeded and followed by a space. Multiple parameters have a space following the comma. For example,
* The following are not permitted
a=b+c
a=(b=1)
myvalue=LEFT(somestring,1)
* The following is used:
a = b + c
a = (b = 1)
myvalue = LEFT(somestring, 1)
5. No abbreviations are allowed.

6. Since the purpose of indentation is to show logical subordination, it is strictly enforced, this includes DO CASE...ENDCASE. CASE < logical condition > is indented beneath DO CASE. Code executing when CASE < logical condition > evaluates to .T. is indented beneath it.

7. Items passed in the parameter list are never modified unless it is the stated purpose of the procedure to do so. Any incoming variable that's needs to be modified on the local level in order for a function to achieve the desired results is assigned to a local variable.

8. Procedures/Functions (applied to method code where appropriate) should do one and only one thing.

Note: This is used to achieve functional cohesion.

9. Rules applicable to achieving loose coupling are applied.

10. All algorithms are proven.

As far as naming of variables, I tend to use Hurgarian notation. For one thing, it's very easy for me to determine, for example, what data type a function is returning by simply looking at the last line of the function. And yes, I do indicate a variable's scope.
George

Ubi caritas et amor, deus ibi est
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform