He actually posted his source code?
I'm not his hero, but I'll contribute to picking his code apart too!
Huge TL;DR incoming.
Just so people know, it's easy to run the ILSpy decompiler against the included 'Assembly-CSharp.dll' and other similar DLLs packaged with a game built with Unity. If you run it against any compiled code that had semi decent source, and the attached image is what happens.
There's a number of pretty obvious things that happen to decompiled code. We'll get to that later.
On his code
The left two are by far the worst, and I would immediately fire whoever wrote code like that, but they also have the most visible signs of being decompiled CIL, with over use of unnecessary 'this', uneccessary casting, and, the variable declarations/initializations (ie, 'RaycastHit raycastHit2 = default(RaycastHit)'), and no comments.
Despite this, they still show some bad practice. All of that nesting in the first one could probably be better organized in function calls or some sort of event system. There are times when this deep of nesting is neccessary inside of a single method, but this probably isn't one of them. If it is decompiled, then there may be inlining to blame for the nesting, but I highly doubt it.
The other one has a big if…elseif…etc chain. Note that the switch statement in my example still decompiles to a switch statement. He probably didn't use one, but should have. switch works on strings in C#. When there are that many options, however, putting the results in some form of data structure, and doing a lookup is perferred, both for performance and readability. Multiple string comparisons are typically slower than a single hash and lookup, but even numbers are bad if there's around a thousand of them- Looking at you, Terraria. Primarily, though, it's much more readable.
It could be reorganized into something like the second attached image. Still not perfect, but something much more easily maintanable and clear, mostly because the WHAT is removed from the HOW.
The third, and fourth, are a little more passable as actual source, but doing shit like 'if (Male == false)' is something inexcusable.
Only other thing is it looks like he's using 'JavaScript' (actually 'UnityScript', but they keep calling it 'JavaScript' though it's a completely different language) - That Color(r, g, b) method is inside of UnityScript, but does not exist in C#.
He might have made a helper method to make it easier, but that's infeasable in a large project, as getting it into every type means you have to bottleneck all classes into one of your own to avoid having to give it context (eg, Helpers.Color(r, g, b)). Still a bad decision.
If he's using a recent version of unity, those 'x.active = true;' lines would cause warnings. There's been a zero-tolerance for such warnings in every single project I've been a part of, again, not a good sign.
Lastly, that fifth one is just a JSON file, and it looks like there's plenty of placeholder stuff in there. Pretty standard practice to load stuff from data files like that.
On Decompiled CIL
Decompiled CIL has a few teltale things:
- lots of 'this' and fully qualified names for pretty much everything
- renamed temporary variables, with name of the type, first name lowercased (and a number, if multiple are defined)
- lots of casting (float), even for constants, if their type doesn't match the destination.
- Sole variable declarations being turned into a declaration and initialization to the default value.
Like I was saying, you can take any Unity game and run its DLLs through a decompiler. The left two are obviously run through a decompiler. The other two weren't. The two that were still have enough bad practice visible in them that I'd throw them out anyway, even if the source they were decompiled from wasn't exactly as aggregiously terrible.
Apparently he actually had a job at some video game company. I'd probably fire a coder like him if I was a programming lead of any kind, if that's actually his source code. much of that code is pretty bad.
It is likely his actual source, but I'm only giving a slight benefit of the doubt to him because of the ease of decompiling C#/Unity, and the fact that plenty of tools can clean up decompiled code.
tl;dr
It's probably his code, Only the left two look like decompiled code, but the practices visible in all of them make me think he's a terrible coder anyway, or at least a fairly inexperienced one.
t. unity programmer
