As software developers we never start out to create weird code. We do our best to keep it neat and sensible, but over time, as the app evolves in ways our initial attempts at organization don’t account for, it can get a little weird. Weird as in someone analyzing the code for the first time would look at it and think,
“Why is this here?”
“Why is this like that?”
“Shouldn’t it be like this?”
That last question is a very dangerous one. As an engineer, when looking at some weird code, the temptation is to impose your way of thinking upon it which can be hard to resist. But know that doing so is risky. Just assume you’re not thinking of something, that your well intentioned refactor has a high likelihood of breaking something. Assume the code is like that for a reason. Practicing this requires humility and an understanding of the limits of your own perception--a sign of a mature and effective programmer.
Leave the weird code alone. Just let it be weird. Just fix the thing you went in there to fix in the first place. Make the smallest possible change you can make and get out.
No programming language is perfectly capable of modeling any sufficiently complex problem space--especially when you're pushing the boundaries of what's possible on the platform. In this respect, code gets weird. It gets weird when our attempts at organization meet the realities of what we're actually trying to deliver to the end user. Sometimes, one must resort to all manner of hacks and clever hoop jumping to get something to work exactly as intended. The end result, in terms of code, can look quite weird.