>>Are tricks also for "Set Procedure To"?
>
>I hate procedure files and when possible, eliminate them. I wrote about that: http://www.tomorrowssolutionsllc.com/Articles/Splitting%20a%20Procedure%20File.PDF
>
agreeing to most, as procedure files have a FoxPro, not OOP smell.

Speed benefit of functions over methods exists, but in most cases is not relevant, so moving into classlibs often makes sense - but into smaller classlibs, grouped according to usage or topic.

Sometimes it does make sense to keep a "topic" function based, for instance if some of the functions are used so often and have bad runtime characteristics that you need to port a few of them to C-fll
Example could be function library to create or work with CSV strings

A few simple rules make such proc libs less painful:
create a function naming schema which identifies the lib the function lives in: csv_whateverfunction()
create method signatures where order of first parameters is consistent

From then on you can code specific hurt point in C if measuring makes it clear a function bogs down the program.

But even for such purposes sometimes it *might* be beneficial to create a classlib first:
If "csv" includes working with separators other than comma (think semicolon for Excel or Tabs), the separator should be defined as a property of the classlib to avoid passing it in each method or function call.

When working on C replacement, such Properties are best NOT accessed in vfp variable space, but copied via access/assign into corresponding C memory space: set once, speed up in every call not needing the parameter.

YMMV
thomas