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

Arnon,

Indeed, .T. is returned implicitly, if the method was called via = This.SomeMethod(). In a situation when no value is RETURNed, testing indicates that this is slower than calling the same method via This.SomeMethod. The only reason that I can attribute to this is the returning of the value.

As for everything returning a value, I think that other means are sometimes available to make this determination. Let's say you want to load an array with some values. I don't return a value from such a procedure. If it fails, then the first element is empty.