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

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

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

>
>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. Read Code Complete where McConnell discourages this kind of stuff. If you're scanning back up a section of code, trying to find where a variable is initialized, it's much easier to find the variable at the left end of a line rather than stuck someplace in the middle of a bunch of variables.

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

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

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