the hard part of this comic chat toolkit project now is figuring out how to factor and organize the classes so that it's easy to use and makes sense, but because I didn't engineer the format there's a lot of work in just re-reviewing the code so far and deciding how to refactor the code so that it breathes well without creating limitations that I might be unaware of, because I don't control the data format at all.
In writing this code, I've so many times realized that two things I thought were separate (or more accurately: could not prove to be identical) were actually related and could be refactored as their own lil' thing. I am still finding things like that over a year later.
The main code file has shrunk considerably as a result, but it's still 1400+ lines right now and I am really trying to figure out a way to split it in half and have some ideas, but it's getting kind of hard to audit how "messy" each split would really be because so many bits of this code are so tightly interrelated.
this is, to me, always the hard part about publishing code. It's no problem writing it, but re-organizing it into nice logical units that are easy to follow along with, understand and modify is another skillset almost entirely.
not to mention I am trying to have this code perform double duty: it should be useful for auditing and analyzing broken, corrupted or mangled files with sufficiently detailed technical feedback for the purposes of performing manual repair/recovery operations, but it should also be a simple, straightforward utility that just Does The Right Thing with minimal guidance, fuss, or jargon-y output.
Two really disparate use cases that have been very tricky to combine into a single codebase. Almost every last print gets routed through some kind of logging helper that needs to make some kind of assessment as to the current context and either just silently store the warning/error, print the log message immediately (possibly adding even more contextual detail), do both of those things, or decide to terminate the program immediately for critical failures.
You can't just always store the info and print it later, because when the error is found might be crucial debugging context that can't always easily be stored and retrieved later. You also can't just always print the message right away, because it might be too much detail or irrelevant to the current user intent.
Example: I, the developer, might want to run this tool in debugging mode and watch how it parses the file to every excruciating detail to help me assess where and why a particular avatar file is corrupt for the purposes of improving the tool to be automatically able to repair certain classes of corruption; or possibly just catch bad assumptions in my own code that don't break anything but are new combinations of inputs I've just never seen before so I can verify that it works as I think or document the new input field value possibilities.
A user might just want to extract the poses from a file and only really cares if it succeeds or not, not be pebbled with every last minute detail filled with jargon that won't mean anything to them. They might, however, want to know if anything "weird" happened or not at a broad level so they can check that the output they got looks right, though. It's a different level of detail. but if the tool fails, probably having the minutiae to send back over to me would be helpful... retroactively!
It turns out that kind of contextual debugging analysis is sort of tricky to both get working correctly and behave in a way that's understandable so you don't wonder why the program sometimes chirps about a warning and sometimes it doesn't; so almost every error carries some kind of very meticulously audited severity level to it.
It's a lot of work for a "joke" project, I guess is my point.