>>That's plain ugly. Is it needed? Probably not. And what the heck is this Functions class? That's VERY much and anti-pattern and non-standard. Lots and lots of code that needs to be maintained just to check and pass parameters is very poor code.
>>
>>Another book I highly recommend is Brownfield Development in .Net. It talks about how to effectively refactor existing code and make it better. I rate it as one of the best tech books I've ever read. But you still need to understand refactoring and patterns.
>>
>>Speaking of anti-patterns. //TODO: is one of them.
>>
>
>Hmm - on the last point - what is supposed to be used instead of TODO: ? I looked it up before implementing
>
>http://www.dotnetperls.com/todo
>
>As for the rest - I guess your comments are valid, but this is what my colleagues (who I think a bit more experienced) have developed to simulate our VFP code. In VFP we were passing parameters as XML string, parsed them and used Invoke method to call. I think that is created is simulates that pattern.
>
>I am just following the suit and code the methods similar to what already have been coded.

I'm 100% with John and Craig on this. As John pointed out your parameter statement is crying out for a structure to be passed in rather than that xml stuff. A strong-typed object will ensure your param is correct and your method can do the (single) task it should be doing.

Also agree about the exit point. You are using return as a way of breaking out of a process when you hit a certain point. Not a good idea. Much better to set variables at each stage ( if you are checking for bad conditions there may be more than one. Even in testing it would be good to find out about all of them on one pass)