Don't Write Inefficient Code.

This suggests, perhaps, that I have watched too many episodes of "Don't" during the pandemic. However, I spent the afternoon cleaning up some really inefficient code in one of our modules this afternoon. I'm not sure exactly how much impact it will have -- we'll know more about that when it gets into testing.

But it will help. I had explained much earlier how to make at least some of these fixes. They were never made.

Until now.

Don't. Write. Inefficient. Code.

*sigh*

This afternoon was spent refactoring someone else's code. I think it's helped, but I need to find out where the other bottlenecks are hiding. Maybe they'll turn up tomorrow.

It's hard to code review a merge between two branches that changes as many files as this one does.

It *looks* ok.

I checked in a new set of APIs at work that substantially clean things up in the project that I'm working on.

Sadly, they are -- unsurprisingly! -- not at all compatible with the old APIs that someone else on the team wrote. This will mean a certain amount of retrofitting is required.

But when it is done, it will be better.

I decided to take some time this afternoon and take a look at the warnings that the static analysis tool in Visual Studio is throwing for one of our C# modules. Most of them are harmless, although some of the (mostly) harmless ones are worth fixing. Some worry me and they are *definitely* getting fixed.

And then I'll test this thing and make sure that it is behaving. :)

I am back to work and -- in and around a lot of meetings -- am continuing my spelunking expedition through some code that I am fixing up. After sufficient inspection of a routine, I can usually remember what it is *supposed* to do. Then I need to see if it's actually *doing* that. And then I need to make it work with the changes that I'm making. All this is very entertaining. And just a bit exhausting.

Today, I stared at three complicated if statements and the code within and rearranged them so that there was slightly more code and fewer if statements. It is remarkable how much more clear the code became. It's still not quite *right*, but I have written comments to indicate what the code is *supposed* to do and -- after I get done with it tomorrow -- that is what it will be *doing*.

This is *way* more work than it should be.

Oh, it *does* look like I solved the problem at work yesterday.

Today, I took a few minutes and deleted the fossil code from the old version of the project that I'm working on. The file went from 2900 lines to 900 lines. So the new code is less than half the length of the old code. Of course, I *did* push a couple of things out to other classes, but even so, it's substantially cleaned up.

The problem when you have long-lived branches in Git (or, I presume, pretty much any version control system) is that you need to keep them updated so that the source code there vaguely resembles what's on the main line. When there's any substantial velocity on the main line, it's worse.

It's worse.

I have two different branches that I've had to do major projects on that I haven't been allowed to merge back to the main line. One of them I hadn't done any work on since early November, which was the last time that I updated it from the main line.

Today's merge took well over an hour as I tried to reconcile the changes and it *still* won't compile correctly.

And now I have an email that says that the *other* branch needs to be updated.

Which is why I keep saying that we need to merge these things.

(We have one branch that is over a year old, because the work I did there hasn't been merged yet. Eek!)