Hi Craig,

>>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.
>
>I've found it easier. You may not. No big deal. As I stated in the actual article "You may not agree with these standards, and that's ok. These have worked well for me."

Whether it is personal or not, it still is damn serious that other people (like Nadya) do think it is a standard that reaches further than your own personal preference and now considers it to use. This is the danger of such personal preference statements: people copy this without asking why and before you know it whole tribes are using it. Sorry to bring it up again, but isn't this exacly what happened with the myth "USE AN INDEX ON DELETED(), IT WILL SPEED UP YOUR QUERIES" ?

Unless it actually makes any sense (good argument, either technical or psychological) I don't see any value in this rule.


>>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.
>
>I did not say "Don't use macro substitution" I said "try to avoid"...which is what you've said here too.

No I did not say try to AVOID marcos. Don't ever avoid macros in DML commands (SQL SELECT, SCAN, LOCATE, REPLACE (more than one record), SET FILTER and many more) that affect more than one record, because it simply outruns EVALUATE(). When we talk about rushmore there is nowhere to go with EVALUATE(), macro's really could boost performance here.

If you're including such remark in your articles it would be nice if some explaination was given in which circumstances the rule applies. You did gave the reader the impression that macros should not be used except in a few occasions (IOW Avoid). IMO, this is not the case especially in DML commands they have very good use (esspecially when rushmore kicks in).


>>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

>Because it is harder to read the code.

Another wrong statement. It's your personal preference. It should be "Because I find it harder to read the code". There is no evidence of any kind that proves your statement nor prove that my prefence below is false:

It is much easier to find a piece of code when you don't have to scroll within the editor. I see no merit in having:

LOCAL Var1
LOCAL Var2
LOCAL Var3

Var1 = 0
Var2 = 0
Var3 = 0

It distracts you from the real algorithm in that method or procedure. Keep the no of vertical lines to minimum WITHOUT loosing readability. It really harms readability if you've got scroll through large number of lines.

Another argument is that the number of variables declared at the top of your procedure should really be limited and the number of vertical lines as well. If you end up with a large number of codelines there probably is something wrong. In my experience developers who have an inheritance out of CLIPPER, FOXBASE, and JSP time do have more problems keeping their no of lines to a minimum than younger developers. But of course this is my observation.

One of the common things that go wrong here is not identifiying you need a subroutine (procedure or method) when you end up doing more or less the same things more than once in a procedure or method (or function).

>>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.

>My own personal testing.

nSec = SECONDS()
FOR nT = 1 TO 1000000
   m.nX = 1000
ENDFOR
WAIT WINDOW STR(SECONDS() - nSec,6,3)

nSec = SECONDS()
FOR nT = 1 TO 1000000
   nX = 1000
ENDFOR
WAIT WINDOW STR(SECONDS() - nSec,6,3)

Does not give me any (significant) difference.

While it could be YOUR personal testing I doubt that you have proven this to be the case. From the readers standpoint it sounds that this observation is proven while I can't see any prove at all. Again this is misleading and does not prove of any scientifical background at all.

>>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.

>Again, my personal testing.

See above. No prove, you're misleading users in that this is proven, while beeing an experienced VFP developer I can't see any prove. While it might be that in some circumstance this is true, you don't inform the users about what the differences are (2%, 100%, 300% improvement) under exactly what conditions.

>>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....

>I've never said these are hard and fast rules. I've stated they are mine and they may not work for you. I agree that people should think about the coding standards they are using and make sure they make sense.

No you never said that. OTOH you mix personal preferences with fact in your article. It is impossible to distinguish between fact and preference if you do not make this clear at each and every statement. You somethimes imply that something is fact while in fact it is not more than a suspicion or personal preference. You did imply that your findings about performance are fact and that you used this as a reason to include it in your code standard.

Example article:

The following is my personal preference. You might or not might agree with this.

1. Blue is the best color for the background of a text.\
2. Labels should be used to display static text.
3. using m. for a variable is faster than omitting it.
4. 2 is less than 3
5. never use grids for inputing data.
6. Grids are too complex for data input.
7. using SEEK on an indexed field is faster than LOCATE FOR
8. _VFP.servername is a very good method to get the name of the executable.
9. Generated PKs are the solution in avoiding "Uniqueness PK violated" errors.

End example.

The example is filled with (partial) facts and opinions, just like your article. Unless you're a experienced VFP developer you can't distinguish between preference and fact.

By your claim (Getting away with such disclaimer), the conclusion is that every article that begins with such disclaimer, does not contain any prove or fact. In fact everything in this article could be the worst nonsense. The one and only value such article has is that it might inform the reader what parameters might be worth thinking about to set up a new code standard.


My opinion is that if you were to make such statements you AT LEAST should explain the background of a rule. In your article you do not give any background information. This makes you article unreliable for any users. It simply gives the wrong message.

Walter,