Now that's bad performance code! once and for all....

Translating an idea into a piece of code is an over-constrained problem, just like many other problems.

To decide how to code something, make a list of all points you think are important for it (maintainability, performance, easy to read by me, easy to reuse by me, flexible, many other pieces will depend on it, multi-platform, multi-compiler, link fast, compile fast, short names for faster typing, easy to read/understand/reuse for my colleagues, easy to read/understand/reuse for my clients, cryptic to prove I am 'old school' and can write assembly and you should be scared of discussing it with me, totally abstract to prove I don't care about performance and want to make a point that premature optimization is the source of all evil, totally lean and mean to prove that non-premature optimization is the road to a lame duck... you name it! I don't care what you put in there, the list can be very long and can include anything you like), score the points in your list based on their utility for the piece of code to be written with the very welcome possibility of zero utility for some of them (makes it less constrained).

You cannot compare apples to oranges? (e.g: maintainability vs. performance) ? yes you can (Yes son, you can compare apples to oranges... )! on top of that, you have no choice...

Finally, code/make compromises to maximize the total score, that's all there is to it and being an over-constrained problem for anything none-trivial it won't be completely obvious.

But the problem is clear, no need to call a programming style 'too old school' or another one 'too abstract' or 'too object oriented'. The higher the total score, the better ... that's it.

Now if u do not have the necessary coding skills, you might generate code that has a total score that is not the maximum possible ... but that is another topic.

.