Thanks for the PR.

Although when it comes to improving code quality (which STK certainly needs), things such as adding or moving #ifdef DEBUG tags to avoid doing a negligible amount of useless computations for asserts in release mode would be fairly low in my priority list.

Hi! thanks for merging it! i agree, but i still think it makes sense to get rid of some compiler warnings in order to make the important ones more visible. now there are too many warnings when building with gcc imho.

what is at the top of the priority list when it comes to improving code quality? replacing raw pointers with smart pointers maybe?

Yes, sometimes some low-importance warnings can clutter output and hide more serious warnings, so it can be useful to get them removed even if it otherwise doesn't matter.

replacing raw pointers with smart pointers maybe?

It's not something that was too high in my concerns, although badly handled pointers can be the source of nasty bugs. Smart pointers definitely have their use to ensure proper ownership rules, but I don't think mass-replacing existing raw pointers without further consideration would really be beneficial. It's hard to comment more without specific cases. A lot of STK's code is quite old, so it's likely that there are cases where smart pointers would be clearly suited where they are not used.

what is at the top of the priority list when it comes to improving code quality?

It's hard to say, because priority has some measure of return on investment, weighting both the benefits and the cost.

What I would rate as the most important is improving STK's structure. This ticket describes some of my gripes with what we have now: #4350

But the amount of work involved to really do that is also quite high. Some of it can be done by small steps, in some other places however it could require much more involved changes. However, long-term, there would be big benefits for continued development with reduced bloat, reduced coupling, more predictable state changes (in my experience with STK, it has not been rare having to look through many many functions referencing each other and having to do many debug prints on the way in order to understand what was going on, because understanding the specific behavior of some distant class or function ended up necessary to understand current behavior or do something that should have been fairly simple).

Also, some part of STK's code also suffer from a lack of proper commenting in addition to poor structure. This is particularly evident in some sections of the networking code, such as server_lobby.cpp. The amount of effort needed to understand existing code creates a barrier to maintenance and development.

Much of STK's development over its history has been driven, beyond attempts at fixing reported bugs, by the implementation of shiny new features. However, this only compounds the code base structural issues.

To say it in few words, I would most welcome changes that delete unnecessary code, coupling and structural bloat.

I don't know if it's something you are ready to do, as it is more involved than fixing some compiler warning, but it would certainly be welcome. If you are interested, it would perhaps be useful to establish a channel to chat, to be able to discuss potential changes without you having to make a PR first.

Also, there are some changes in the 2.x branch (intended to be merged in the main branch after 1.5, accessible at https://github.com/supertuxkart/stk-code/tree/BalanceSTK2) that either do some cleanup not present in master or could cause conflict for later merging for some code improvement commits.