I'll just add another 2 cents. Function naming conventions can go a long way in making a UDF easy and intuitive to use. This may go without saying, but sometimes its helpful to embed a variable type name within ones UDF name, for example:

ReadProfileString - returns a string
CreateObject - returns an object
SortArray - sorts an array and returns an array

And sometimes certain keywords conventions can be used as a tipoff as to what the function does and what it returns.

InGroup - the keyword "In" usually denotes that this function returns a boolean.

IsUpper - same as "In" - returns a boolean

AsLower - "As" meaning that this function transforms the input parameter or returns a variable of a different type (eg, AsNumber("3"))

GetFileSize - "Size" meaning that this function returns a number

I`ve always liked the old "action-object-type" naming convention for functions, you know, function names that start with an action (get,is,check,read) then an object name (File,String,Profile) then optionally, an attribute of that object (Size,Handle,Upper), for example:

GetFileHandle()
IsStringUpper()
ReadProfileString()

Anyway, im just rambling again, anyone have anything to add about function naming conventions ?

-Shawn

[ 23 April 2002, 22:52: Message edited by: Shawn ]