Well, Craig's advice, as well as others' are good and always explain that they are not completely a "must be" they just say "use it whenever possible" or "try to avoid it". They don't say "use it always" or "avoid it". And as long as code standards concern, Me, as well as any other VFP developer knows that there isn't an absolute standard and it always depends on the way one develops or see fit. Finally, my name isn't Lious, it is Luis.

Best regards,

Luis Guerra




>Hi Lious,
>
>I did not say that his standard is old, but it is based on old standpoints. There is NO, I repeat NO one code standard. Code standards are extremely usefull for project where more than one developer is working on. There are many different code standards.
>
>But all code standards have common goals, for example:
>
>1. Consistent naming of Variable and objects
>2. Consistent code layout.
>3. Consistent commenting
>4. Maximize readability
>5. Language depended code rule.
>6. .....
>
>1. Consistent Variable and object naming. Many use the hungarian notation in some form. Note that only few use the pure hungarian notation. The rest who claims to use this notation only uses a mutated form of it.
>
>My standpoint of this is that in the OOP your designgoal is to have many short procedures or methods in stead of one long procedure (Jackson Structure Programming, approach) find in many Clipper and early Fox programs. When coding short methods and programs I don't find it usefull to have a scope identifier. By looking at the code you'll see fast enough what the scope of the program is:
>
>- locals are declared at the beginning of the method/program.
>- Parameters are listed at the top of the method/program.
>- Private and globals should be limited to only a few which are so obvious to the program that they need little or no explaination.
>
>Personally I do use a type operator (n = numeric, d = date, c = Character, l = logical) but some don't find this neccesary as well. Examples:
>
>dDateFrom
>cName
>lFound
>nAmount
>
>I don't take the effort of having more identifiers for Memo, Currency, integer, double fields as they're implementation specific. Their type in code is compatible with Character, Numeric, Numeric, Numeric respectively. If you change the underlying fieldtype (which in general does not give any problems at all) the type identifier does not match anymore if you distinguis between those types.
>
>Also many code standards do recomment the CamelCase naming. Don't use spaces or underscores but use the case in a variable to make a distinction between words. example: nThisIsAVariable.
>
>For objects naming I personally don't care that much. As long as code references to objects are clear you can name them anything you want. It's useless to waste time to name objects that are never referenced in code but only used in the GUI (e.g. labels and other objects bound to a field directly).
>
>2. Consistent code layout. I think all common code standards have a few rules in common.
>- Declare locals at the top of your program
>- Use indenting for readability purposes. In most standards TABs are recommended.
>
>3. Don't overdo commenting. Comments do distract you from what is really happening in code. I personally hate those methods that contain about 20 lines of comment and only 2 or 3 lines of code. Unless it is neccesary for explaining what is happening don't use extra comments. You're efforts on producing readable and effective code and usefull names of methods and procedures are much more appriciated than you commenting skills. Sometimes one well placed comment is far more helpfull than 20 others.
>
>4. Maximizing readability. As said before indenthing is one of the most effective weapon for readability. Also don't overdo comments. Comments take up space. A short generally procedure is more readable than a long one. The same procedure with only a few effective lines of code is far more readable that a method where lots of useless comments are listed.
>
>5. Language depended code rules.
>I really disagree on some point of Craig on this issue. For example:
>
>a. Line continuation: I dont care if you're coding:
>
>

IF Somecondition AND ;
>     Some condition2

>OR
>

IF Somecondition ;
>     AND Some condition2

>I simply don't see one is better readable than the other. Just choose one, and stick to it.
>
>b. Try to avoid macro substitution: BAD ADVICE !!. It should be: Know where to use either macro substitution and where to use EVALUATE(). They're very simular but have the difference in that a command line containing a macro is compiled at runtime and that line is executed whereas the line with EVALUATE() is compiled at compiletime and the expression between the brackets is evaluated for each time the line or clause is run.
>
>Avoid EVALUATE() in commands that are interpretated once but its clauses are executed many times:
>e.g.: SQL - SELECT command, LOCATE, SCAN, REPLACE ALL etc.
>
>Avoid macros in other commands where EVALUATE() can be used.
>
>c. Avoid the use of STORE. Craig typically forgets to say why. I really don't know why he wants to avoid store and up to what level. STORE makes a realy good case in the following examples
>
>

>LOCAL nVar1, nVar2, nVar3
>LOCAL aArray[200]
>
>STORE 0 TO nVar1, nVar2, nVar3
>STORE "" TO aArray

>
>d. Avoid the use of m. on the left side of an equal sign. It will improve performance.
>
>I do remember that there was one case where this 'could' be an issue. However, in many cases it does not have any performance effect at all. When a table is selected with many fields, using the m. operator actually is (much) faster . Again craig fails to give a good explanation what is the background of this rule.
>
>
>e. When doing a string concatenation, put the variable on the left side of the + sign. It will improve perfomance.
>
>Again, no explanation. Further this rule might be version depended and thus should no be described in the coding standard.
>
>
>My message is that you should think yourself about these things rather than blindly listen to the GURU. Of course many times it makes sense, but this does not mean you don't have to validate those rules yourself. Again THINK....
>
>One of the common rules is to only return at the end of the procedure, never use LOOP or EXIT.
>Of course most of the time they make sense, but like all things in life there are exceptions. So a colleage of mine was working with some guy who had blindly followed these rules. he wrote something like this
>
>

FOR nT = 1 TO 1000
>    ....
>    IF lSomeConditionThatCouldNoBeDeterminedAtForeHand
>        nT = 1000
>    ENDIF
>ENDFOR

>
>Well what the hell are you doing here ? Just replacing the EXIT with a nT = 1000 ? Well that really does help readability is it !?!
>
>Of course he'd better programmed it like this:
>
>

nT = 1
>lExit = .F.
>DO WHILE nT =< 1000 AND !lExit
>    ....
>
>    lExit = lSomeConditionThatCouldNoBeDeterminedAtForeHand
>    nT = nT +1
>ENDDO

>
>But this is really not the point. While I agree you must try to avoid EXIT, LOOP and RETURN in the middle of a program, this not a holy rule. In a few occasions you might need to do so.
>
>You just try to avoid exiting a procedure or loop this way because it has a negative effect on readability, flow control, cleaning up code at the end of a procedure, error handling with TRY, CATCH and FINALLY etc. You really should have a good reason to use them.
>
>So bottom line. You can read a lot about code standards but as long as you don't know or can't see what is the benefit of a certain rule don't take it for granted. THINK about it and check it's validity. When Craig says it is faster, you better check when it is faster and what the performance difference is. If your program has a performance issue, removing or adding the m. prefix for code lines that are executed only few times is not going to solve your problem.
>
>It might be far better to look at someone else his code. Try to see what code standard he's using. Pickout the good things and use them.
>
>Walter,