Finding Replacements

Hello all, hope you’ve all had a lovely month. Last time around, I spoke about the types of considerations that needed to be taken into account when sorting an issue out and programming—using the anti-spam system as an example—and now I’ll be talking about another sort of issue of organization.

As I’ve mentioned here and there over the years, the base code of Kusaba X is something of a mess. Things like inconsistent style (spacing, how functions are named) are the least of it; there is a dearth of good comments in the majority of the code; unintended behavior, especially with regards to cleanups; a lot of repetitive and duplicated code; slow or resource-intensive solutions to some operations; there’s also a lot of just outright old code that even for the time was not best-practice—a lot of that has been deprecated in newer versions of PHP. Of course, as I’ve attested to in several posts, I have had to interact with a lot of this, often precipitating rewrites and debugging.

When I was doing some of the work necessary for the anti-spam stuff, I once again found that it there was old code getting in the way. So I decided to do something a bit more comprehensive than the usual rewriting relevant bits of code. I set aside time to examine code on a larger scale, using debuggers and other tools to find many parts of the code base that were problematic.

The result of the above was that a couple hundred lines of code were affected in some way.

Granted, I’ll level with you and freely admit that most of these are incredibly minor changes—think removing or adding spaces for formatting’s sake, or improving comments here and there. That’s a quality-of-life type of thing for me as it’s easier to parse code when it’s formatted consistently.  Standardizing descriptions and documenting functions is still a pipe dream for most things so comments are usually a short line or couple of words here and there. Still, if well-placed, these can be very useful reminders and time-savers when revisiting parts of the code many months or years after the fact.

Other changes were more significant, along the lines of catching a few bugs that had gone unnoticed for quite some time or making checks and comparison operations a little stricter in places so to avoid potential buggy behavior. PHP is fairly nonrestrictive with its typing and conversions and, while it tends not to be a problem, under some circumstances it can lead to nonsense values being returned and the program not executing as expected. The bulk of the affected code related to more rarely used things, such as management-side tools, but a few related to how posts and threads are generated and were worth the effort to sort out.

Still more effort was spent in ensuring code correctness and modernizing syntax where appropriate. As mentioned earlier, some of the code assumes ancient versions of PHP and because of a mix of age and compatibility efforts, Kusaba X was designed in a way that makes maintainability challenging. While most of the critical that was outright deprecated (especially in classes) was fixed by me several years ago, before the jump to PHP 7, there’s a lot that’s in a grey area or looks likely to be deprecated in future versions of the programming language. Some behavior has changed subtly in more modern PHP as well so rewriting things in a less ambiguous way makes more sense when you’ve got an eye to the future.

These concerns weren’t all just hypothetical. In my test environment I found that there were errors with some common features, like tripcode generation, with newer versions of PHP. Most of the issue was centered around an array of values that was serialized as a workaround to old limits to constants and their attributes. As the rationale in the original code was uncommented, I had to forensically exam things step by step while looking at the various release notes and manuals for newer PHP versions. This sort of sleuthing also led me to detect other issues—like with image generation and file cleanup—that had workarounds for old Windows-only behavior on older versions of PHP. I duly excised what I found.

THP ought to now be fully compatible with the latest stable release of PHP and looks to remain compatible for the foreseeable future. My test environment works well and the only errors and warnings are from the few third-party libraries the site uses. They should have new releases in the coming weeks which ought to fix those bugs. Once all that’s done and I do more testing, I’ll be able to roll out the changes onto the production server and also possibly upgrade its PHP version while I’m at it.

Barring any unforeseen bugs I haven’t caught, the fact that the minimum standards of code are reasonably modern is also helpful for future development. I have yet to begin work in earnest for some of the larger overhauls but I had been thinking about potentially using features found in newer versions of PHP. I’d like to eventually get rid of most of the old Kusaba X code, even if just in a Ship of Theseus sort of way. The further away that THP is from paradigms created 15+ years ago, the better when it comes to forging our own identity and way of doing things. I’ll be talking about those developments when I get to them but taking care of the code base makes for a sturdier foundation.

I’ll end this post with something of a spoiler for the next thing that’s getting a few changes: the story list. I won’t get into it now but there have been several improvements I’ve been meaning to make that I’ve finally gotten around to. It’s not all yet ready to ship and it may take a few more weeks, depending on my free time.  As I’m also waiting for other libraries to be updated before I roll out more changes to the site, deployment might take longer than that. Still, although it’s nothing revolutionary, I think they’re nice quality-of-life changes and will leave things in a state that I’m satisfied with until far larger changes to the site are ready. I’ll get into it next time around.

Until next time, take it easy!