Also, I believe you’re talking about the overhead of referencing and retrieving variables from encapsulated classes. If performance matters to you, there are ways to speed that up. One is to simply get a pointer to the object and store it locally, and another is to copy the data to a local variable and pass back the value when you’re done.

OOP does have a slight overhead in exchange for better maintainability in your code. However, it doesn’t matter how fast your code is if it’s not maintainable or buggy. But there are plenty of software engineering concepts you can use to speed up your code without making it ugly and unmaintainable.

When you program in a large team, they all have coding practices that you must follow. This is nothing new, this is just my way of doing things for people who haven’t been exposed to these concepts. So feel free to disagree, but each guideline is explained on why I use those methods.

Well, actually overall it doesn’t. But you are a bit on the dogmatic side. If something is the right tool or technique for the job, you use it. Don’t use something else because you took a blood oath NEVER to use * Recently I worked in Lua, in a game related environment. You had a meg or two total for graphics, sound, and code. It goes very quickly. Brevity in variable and function names was a necessity. On the subject of naming conventions, if it works for you and anyone else you work with, it’s good. All class variables should be private? Encapsulation has it’s advantages. But if you are working in a graphics intensive environment, you may sweat every cycle. How much time you spend going through functions to get at variables only your profiler knows for sure. But if speed is critical, perhaps you should have direct access. Drifting back to my core point, it’s good to have guidelines. But never say never. Use the right tool for the job.