Refactoring Legacy Code (2014)

I have a lot of sympathy having also cut my teeth trying to improve the maintainability of a DikuMUD based variant. There were some pretty crazy anti-patterns in that code base - most of which originated with developer-lites, people who ran the MUD and just hacked at the code until it did what was needed.<p>I&#x27;m not certain if it also applies to FotR but the MUD I worked on also had an incredibly failable persistence strategy involving a lot of flat files that were written to in sequence - weirdly it also had a rather impressive code hot-swap system that allowed the binary to be swapped out during execution so thankfully the system wasn&#x27;t brought down that often.

interesting read. Here&#x27;s how I understand the outline<p>* transition version control to Git<p>* Removed commented out blocks<p>* Add clang-format to the codebase<p>* remove support for old operating systems<p>* fix clang warnings and memory bugs<p>* reorganize sections of code changing behavior minimally<p>* add unit tests<p>* update compiler to clang++<p>* refactor and add new functionality

Yeah that’s all really bad, but the worst I ever saw was some c with the comment at the top<p>&#x2F;* converted with f2c dec 2001 *&#x2F;<p>I had to to fix some buffer overflow and int overflow issues flagged by an automated scanner. 2000 line function with about 50 labels and gotos in there.<p>Working on it was actually kind of zen, it was just one file though, any more would’ve been unbearable.

Concerning the latency problem over ssh: switching to mosh would probably help a lot (and any downside to using mosh goes away when one is using tmux anyway).

&gt; I also found a back-door in the MUD that was inserted by a previous maintainer.<p>YIKES. This strikes me as the kind of thing that happens when you don’t use version control.