>
>Which isn't too hard - I tried, and it's something you can teach yourself in a few tries and a few meals' practice. Which actually comes handy when the salad dish is on my right, I simply take the knife in my left and fork in my right and can enjoy my meal without extra maneuvering :).
>
>As for procedural vs OOP, I keep running into something I learned when I was replacing my procedural head with the OOP one: the main question of OOP is "where does the code go". If you don't know where to put code which does something, or you have a hunch but can't explain to yourself, then just don't. Sit a while and think it over, or call an Auntie Emma.
>
>My simple test to see whether some code goes into this or that class is to ask "what does this class do, what's it in charge of?". If the code isn't part of that, then it doesn't belong in this class. Then it's "so what does this code do?", and the answer to that helps me see where it will go. Maybe it's a worm from a can I haven't opened yet - if it is, then design a new class. Doing so usually rings some bells and few other stray pieces of code fall naturally into this new class.
>
>Practicing this kind of mental discipline has earned me lots of hours of undisturbed sleep :).


It's a shame that good OOP practices haven't been pushed more hard in the VFP community. Most code samples you got from FoxPro were really not worrying about good design.