Gyrations

It’s instructive to walk through code sometimes. It reveals a lot more than just scanning it at a high level.

One of the things you find is that the code might take some pretty odd paths through the logic, just to get back to some really simple data changes.

These gyrations are of course unnecessary. They usually exist because the programmer didn’t know how to go from A to B. Instead, they went skewing off to H, bounced over to M, and then came back to B.

Sometimes this is a result of a second programmer coming into the code, with the intent to ‘just fix’ the minimum necessary. 

Sometimes it is a result of the original programmer not fully understanding the work they are doing. For some coders, they have a discreet set of ‘instructions’ that produce certain types of output. They assemble their code from this set. If this set has gaps, their code also has gaps, so they fill them by jumping over to other areas that they have in their set, doing intermediately work, then eventually jumping back. That is, they know how to go from H to M, and they know how to go from A to H, and from M to B. This can be recursive and often quite intertwined, there can be some pretty crazy gyrations going on.

It’s far easier if you want to code A to B, to just code A to B, even if there aren’t any underlying libraries that help. Most of these transformations are pretty trivial, they involve basic data type changes or structural rearrangements. If it turns out that it is not possible for scheduling reasons to do the code yourself, then the best way to handle this is to craft a function to encapsulate A to B. In that function, you can throw H and M into the mix, that’s okay. Later, if another programmer sees this and knows how to be more straightforward, it’s pretty safe for them to just replace the H and M madness with better code. If it’s encapsulated, then the impact of this change is easy to figure out. 

Sometimes programmers don’t want to encapsulate A to B because they feel that it is either hard to read or slow in performance. Neither issue really applies. It’s easier to read code if the weirdness is pulled away from it. You get a bigger sense of what the logic is trying to accomplish. The performance costs of adding lots of functions have been effectively trivial for decades. There are certain types of high-performance code where it might matter, but chances are that is not the code you are writing right now, and even if it was, it’s better to also provide a slower, more stable, more debuggable version in the source as well.

The biggest problem with large systems is that any and all disorganization feeds into making it a tangled mass of spaghetti. This always starts with little stuff, and each problem itself does not seem significant, but as these problems stack on top of each other, the entire edifice grows shaky and difficult. In a sense, passing through H and M is entirely artificial. They weren’t really needed, they are wasting resources, and they are just confusing the code. The code needs to get B from A, and it needs to do that in the clearest and cleanest way possible. Even if you are rushed, encapsulating that in a little function doesn’t take more than a few minutes, and it will pay off immensely later. 

Fixing this is actually really easy. Just start going through the big functions, creating littler ones. Once you have little ones, revise them to fit into other places in the code. Sometimes you have to unwind it a little to get it cleaned up. So, if A->H->M->B is intertwined with A’->Q->X->N->C, you probably need to separate them first, before you can encapsulate them. Obviously, it was less work to get it right originally, but it’s not complicated work to sit there and unravel it either. It’s just slow and boring. You have to do it a little at a time, then check that the code still runs correctly, then continue on. It definitely is work worth doing, particularly if there are still big changes to the system that are coming. Ignoring it only makes it worse.