>>There is stuff that is not wise to have in classes. And instantiating odd objects with each and any form just to use a single method is a lot of overhead compared with a procedure. Global classes solve not any problem, because the run in different DATAENVIRONMENTS. Procedures run in the one calling.
>>The purist OOP-only days are over - if you are happy with your procedures, use it. The only downside I see is that, the visual interface to edit methods is much nicer then scrolling through huge PRG's. (Don't get me started on 32605 lines of FoxBin2PRg.prg ...)
>
>I have not looked at the number of lines in my PRG files. Each .PRG File has procedures/function related to a specific feature in the application. Or a module. So they are logically set; I didn't just dump all procedures and all function in one .PRG.

What is perfectly fine (for you). Don't let your style of programming get disturbed by pure academic nonsense on this place. It's yours. There is only one important to a program: It must run on customers comp and act as expected. You don't get paid for nice looking code.

The oddest I ever saw was VFP coded in ASM86 style. With the same style of spacing and each line with line comment same column.
Programmer understand the code, so what's up?

Any coding rules are not rules. they are hints, ideas but not law. (Except you work one somebody elses code or join something)