Howard:

That was an interesting example. I'm surprised it works... I guess this is an example of an array of variants? Either that or an array can contain mixed types. I wouldn't have expected that, but then again, I haven't dug into the internals of KiXtart nearly as much as a few others here. Some of these folks probably get coding projects handed off to them on the sly by Ruud. [Wink]

Yet, the problem still remains that if I expect (for example) an integer to be returned and I get an array, it adds to the complexity of how I deal with the result. Admitted, this is a trivial addition, and you may find the added information returned to be very useful. However, it is non-intuitive and could be problematic to those not used to working with arrays.

Richard's idea of object properties is very intriguing. I like it, but have no idea how that could be made to work.

As for those arguing 'simpler is always better', I would have to disagree. Often external simplicity and power is at the cost of great internal complexity. So long as the end user doesn't have to understand the internal complexity, and that complexity doesn't cost too much in performance / resources, I'm for it. A GUI is incredibly complex, but my four-year-old is able to open programs, enter data (her name), and play games involving selection and manipulation of on-screen objects after only minimal instruction. Behind that 'simplicity' are millions of lines of code and many, many standards of coding and inter-process communication.

Programming is 10 percent core logic and 90 percent interface logic. Obviously, this isn't nearly so much of an issue with UDF's, but I appreciate the following 'best practices' in some of the coolest UDF's I've seen:

1. They are pretty much unbreakable. They prevent or handle internal errors to the greatest extent possible. They still return a value of the type expected if they break -- thus helping prevent type mismatches -- but the value is zero, empty, or null. If the values supplied should never return this data, the data itself can act as the error. Otherwise, the function should set an error number on exit to be tested.

2. They are independent. All internal variables are declared so they will not be confused with global variables. (Side note -- Howard, I notice you tend to 'Dim' your argument variables as well. Unless I'm misunderstanding the process, this happens automatically simply because they are arguments.) Also, files are opened and closed in a way that they can't interfere with file numbers in the calling script.

3. They return what I intuitively expect. This way I don't have to dig through the code to see what is going on. In other words, most numeric functions returns a number. Most string functions return a string. There are obvious exceptions, of course. I would expect instr() to return a number. But I would be very surprised if it returned an array!

4. They are well documented and tested. Even better if extensive testing code is available along with expected results so I can verify those results on my particular combination of HW/OS/KiX versions before implementing the function.

5. They are readable so I can customize, if so desired. (This is strictly a personal preference. Most people probably only want to use a UDF, not tinker with it.)

I don't give a rip about 'function police' [motto - "Badges? We don' need no steenking badges!"] , and I don't think that is where this is going.

However, I welcome ideas and feedback on how to write better, cleaner, more robust code. And the more the most active KiXtart developers can agree on 'best practices', the more the entire KiXtart community benefits -- not only from better scripts and functions, but also from the respect of other scripting communities.

Cheers from a crazy idealist,

New Mexico Mark