I've been working on Lokasenna_GUI for a couple of years now, and it's still fun. It continues to be a great exercise in organization, source management, and having other people depend on my work not breaking. Even better, I learn something new with almost bug I fix or feature I add.

But... it's messy. In programmers' parlance, it smells - nay, reeks. Any bugs that pop up are often in repeated in a few places, and features I want to add are often not practical because of the amount of work it would take to fit them in without breaking something else at the same time.

What's a fellow to do? Easy, you might say: Nuke it and start over from scratch.

Well, no. It took a lot of work to get my GUI to where it is and a lot of the code is still good. It's just all tangled up like in the '80s when your cassette deck would break and start spewing out meters and meters of tape all over the place.

But what if there were a way to carefully pull it apart until the tangles are all smoothed out, making it straightforward to rewrite or replace code as needed?

Refactoring

Factoring: Breaking a complex problem or system into parts that are easier to conceive, understand, program, and maintain.

Re-: Again.

Refactoring, then, is the process of making changes to code that don't directly change its functionality.

That's all well and good, but how do we do it? First, we need to know what we can refactor:

1. Chunks of code that could survive on their own without reference to the rest of the app. They don't necessarily have to be useable without other code, merely self-contained. A kitchen would be useless without a house, but it definitely doesn't need to take up space in the bedroom and attic.
2. Chunks of code that are repeated, either exactly or very similarly. If you can pull these out into one piece that the original locations reference, you reduce the potential for bugs, make changes more efficient, and quite simply reduce the size of your codebase.
3. Concepts that could survive on their own, like having your "office" in a corner of the bedroom when you could clear out the spare room and actually have a dedicated space. For us, this might be a bunch of text-processing code in a script dealing primarily with MIDI, or graphical functions scattered throughout the "business logic" parts of your script.

Second, we need a way to do this in a somewhat organized fashion:

1. Make a list of what you identify, being as specific as possible. This list will probably grow as you tidy up your code and notice more possibilities for refactoring.
2. Have a few test scripts that you can run to make sure everything is still working properly.
3. Check them really, really often so if something breaks, you know exactly where it must have happened.
4. Try to work on only one thing at a time. This severely limits the scope of potential problems that might show up, so that when something breaks you can often know exactly which two lines are at fault.
5. Make use of whatever your language has for modules, importing, etc. to keep separate concepts and tasks in separate files. In the past I've been pretty bad for this - my GUI was originally one 5000-line file and it was... unpleasant, shall we say?... to navigate.

---

In the next post I'll discuss the issues I've identified, solutions I'm planning to work toward, and what I'd like the GUI library to look like when its all said and done.