>>11237911Alex's "source" code that people are "reviewing" actually comes from a decompiler, which basically means the "source" code was reverse engineered from the executable code that he distributes for the game. This means that much of the structure behind the code is lost, and what you have left tends to more closely represent low-level code, which makes it look like poorly written code, since the compiler cannot reconstruct most of the facilities that Alex probably uses in his code. Functions will be inlined. Variables will be lost. Macros can't be unevaluated. If the compiler translates a switch statement into low-level code that works the same way as an if statement, the decompiler would have no way of knowing whether a switch statement or an if statement was used in the source code.
If Alex did use if statements instead of switch statements (which I think he actually does), this would only negligibly affect the performance of the code, if at all. He's writing a video game. An overwhelming majority of the compute needed for running a 3D video game lies in graphics rendering, not game logic. Now here's the kicker: C# doesn't compile to machine code. It compiles to bytecode. The instructions that the compiler translates the source code into aren't run directly by the processor. They are run through an interpreter. That's because C# is a scripting language. It doesn't need to be highly performant. It isn't being used for code that needs to be particularly fast. The use of a jump table would be an inappropriate kind of optimization to make, generally. The decision to use switch statements would really be nothing more than a matter of personal preference. The people who design scripting languages know this. Python, Perl and plenty of other scripting languages don't even have switch statements.