General refactor of MTA's code
I changed most of #ifdef WIN32 to #ifdef _WIN32 because WIN32 was not always defined in some files. _WIN32 however is always active
i took a look at what did you do and i have few things to say:
- reply << (unsigned char)(temp.str().length() + 1);
+ reply << (uchar)(temp.str().length() + 1);
we should probably use types from https://en.cppreference.com/w/cpp/types/integer if we are going to refactor something, so in this case uchar should be uint8_t
I'm not good at windows headers so i have a bit concern about changes you have made regarding that
If function has depth of 1, maybe 2 levels we probably should keep it as is.
Even if you compiled it, and it works, you should probably try to run some bigger gamemode to test more scenarious
I think if you are doing such big refactor, split it into smaller parts, sections or however you name them, so in one pr you refactor all types like "unsigned short" to "ushort", in the next you decreasing depth of functions ect. it's a general good advice so reviewers have easier time
i took a look at what did you do and i have few things to say:
- reply << (unsigned char)(temp.str().length() + 1); + reply << (uchar)(temp.str().length() + 1);we should probably use types from https://en.cppreference.com/w/cpp/types/integer if we are going to refactor something, so in this case uchar should be uint8_t
I'm not good at windows headers so i have a bit concern about changes you have made regarding that
If function has depth of 1, maybe 2 levels we probably should keep it as is.
Even if you compiled it, and it works, you should probably try to run some bigger gamemode to test more scenarious
I think if you are doing such big refactor, split it into smaller parts, sections or however you name them, so in one pr you refactor all types like "unsigned short" to "ushort", in the next you decreasing depth of functions ect. it's a general good advice so reviewers have easier time
well, then just a quick change from all utype to u/int8-64 would fix that
The derefencing such as for (const auto& pWater : *g_pGame->GetWaterManager()) is counterintuitive and makes it difficult to read the code. It's better to add a dedicated method for getting inner objects like for (const auto& pWater : g_pGame->GetWaterManager()->GetWaters()).
The derefencing such as
for (const auto& pWater : *g_pGame->GetWaterManager())is counterintuitive and makes it difficult to read the code. It's better to add a dedicated method for getting inner objects likefor (const auto& pWater : g_pGame->GetWaterManager()->GetWaters()).
I agree on this one, it's not clear 100% clear what *g_pGame->GetWaterManager() is going to be.
This draft pull request is stale because it has been open for at least 90 days with no activity. Please continue on your draft pull request or it will be closed in 30 days automatically.
This draft pull request was closed because it has been marked stale for 30 days with no activity.