>>If the method returns a value, don't you have to use parenthesis?
>
>I break individual code modules into two separate categories: Procedures and Functions. I define these as follows:
>
>Procedures accomplish a task.
>
>Functions return a value.
>
>I realize full well that in the various versions of FoxPro, that these are pretty much interchangeable terms. However, I prefer to stick with the standard computer science definitions. I think it help readability. If I see code that begins PROCEDURE, I know that it: a.) Doesn't return a value; and b.) the parameters may be modified. If I see one that begins FUNCTION, I know that it returns a value, the parameters probably (but not always) are not modified. This is one reason why I use PRGs for non-visual classes.
>
>In terms of visual objects and their methods, the calling method should demonstrate what it is. I short, I never call something that I consider a PROCEDURE with: = This.SomeMethod (besides, it's slower than just This.SomeMethod). On the other hand, a FUNCTION is always called with: lValueReturned = This.SomeMethod().

I have to say that I hardly use what you would call procedures anymore
as even if a method just perform a task - almost always it will at least return a .T. or .F. to show if it was sucessful or not
also note that if you do not return a value a .T. is still returned implicitly

Arnon