Security through simplification of source code

Way too many soydevs (especially graduates, which are usually all soydevs anyway) believe that in order to make your code more secure, you’ll need to add even more complexity, add even more abstraction, add even more bloat, make your code even more unreadable, and all that.
However, this is proprietary way of thinking, and will only work on paper.
In practise however, the exact opposite of that is true.

By making your code more complex, abstract, bloated, and unreadable, you don’t fix security holes, you only create new security holes.
I remember my first ever personal project, sure it wasn’t soydevvery, but the soyce code was still very unreadable.
Every time somebody reported a bug, it felt like I got punished for having to read my own code and try to fix it, or even figure out how the bug even happens in the first place.
Luckily it was all procedural code, so it was easy to know what file I had to edit to fix the bug, and I never had to jump from file to file and debug every single class just to solve 1 problem like what is always the case with object oriented code.

But that one experience is what let me to set rules for myself, like keep code short, simple, and to the point, make use of proper indenting to make it easier to see where shit goes wrong, purge all unused code as soon as you no longer use it (so don’t wait until you’re about to release the final product), and so on.
Luckily I didn’t have to teach myself to make sure my code is 100% self written, simply because back when I started coding PHP, there were no frameworks yet, even the whole concept of MVC in web development didn’t exist yet.

Over time I started adding in more rules, like total size of the project (excluding ASSets like images, videos, favicons, databases etc, but including HTML, CSS, JS, PHP or Go) should never exceed 1 MiB (or 1024 KiB, or 1.48 MB), which in many cases is quite a lot of space.
In perspective, the comments section is only 1.58 KiB (1.62 kB), Hozon Site is only 10.93 KiB (11.19 kB), URL Loli is only 6.86 KiB (7.02 kB), and Kensaku Online is 15.81 KiB (16.19 kB) for now (the last one can signigicantly change, as it’s still in development).
With the exception of my comments section, they’re all full blown web applications, and none of them exceed 20 KiB (again, for now), and my biggest project I made for a customer was a around 600 KiB (614.4 kB) total (would be 90 MiB if you include all the ASSets, but then again those aren’t editable code anyway), so 1 MiB is actually extremely generous.
I only made the limit to be 1 MiB to allow complex management systems that require lots of code, but even with complex CRM systems I never manage to hit that limit.

For the GenXers and millenials out there, 1 MiB fits on 1 floppy disc.

It is however important that you don’t make use of any frameworks at all, because just initiating one alone will shit out somewhere between 10 and 800 MiB of bloat, and that’s before you even write a single letter of code, mind you.

However, one mistake game devs often make is that they optimize code to make it use as little resources as possible, only to then make space for over the top bloated graphics and audio.
That too should be avoided, but not for bug fixing purposes, but rather for sustainability reasons (and I mean real sustainability, not that new world order SDGs scam).
But that’s a topic for another time.