Legacy code – two words to strike fear into the hearts of developers everywhere. Pretty much anyone who has worked on an established code base has had the experience of opening up a file, only to find a horrific mess which looks like a cat has walked across the developer’s keyboard. It’s a truly harrowing experience the first time you see it.
It’s very likely that the file you just opened was written more than a decade ago. Why was that code written like this, and how did it survive so long without being rewritten?
The seemingly unstoppable advance of technology is part of the key to understanding why legacy code often looks the way it does. A decade or two ago, storage space was limited and bandwidth was expensive. To combat this, short variable and file names were encouraged by developers, or even required by the language itself. If you could save a few bytes by requesting ‘cmp.asp’ instead of ‘companies.asp’ from the server, that would add up. If you could replace every instance of ‘connection’ in your code with ‘conn’, you’ll be able to store a bunch of extra files on your computer.
Working with Legacy Code
We’re lucky to live in a time where these concerns are no longer as prevalent, with bandwidth being cheap and storage even cheaper, but we still have to work with code which was written when these concerns were an issue. In an ideal world, we could rewrite our old code to be up to modern standards, but sadly, that takes valuable development time, and means re-testing old code which (theoretically) already works.
The cheapest solution to “fix” legacy code is documentation. If you’ve spent 10 minutes wracking your brain to understand a complex piece of logic, taking another minute or two to add a comment explaining it will save future developers the struggle.
But fixing old code isn’t the only important thing. We can’t see the future of technology, and in 15 years, the code we write today might look as foreign as the code written 15 years ago looks now. We need to write code that not only works, but can be understood and improved in the future. Here are a few ways you can make sure your code is ready for the future.
Consistency is key when it comes to writing maintainable code. It doesn’t matter if your code is written in an alienated style, as long as all of it is written the same way. That way, future developers only have to figure it out once. If your team has a set of rigorous code standards, learn them and stick to them and everyone’s lives will be easier. If they don’t, ask why! Request them! Write them yourself, if you have to!
If You Really Need Small Code, Use a Minifier
If code needs to be sent over a network, especially the Internet, there’s still a good argument for having small code. There’s no reason to write your code small, however. Minifiers will reduce the length of your code so you can write your code in a readable fashion. Keep the full-size code for development, and minify when it’s time to release. Just make sure you test the minified code, to make sure the minifier hasn’t broken it!
Comments and Documentation
Believe it or not, comments actually have a use outside of temporarily removing a piece of code! Well written comments can make a complex piece of code a breeze to understand. Yes, the best comment is clear and well written code, but the second best comment is a comment, so don’t be afraid to use them! In addition to in-line comments, adding a comment at the top of a file or a function can mean your code rarely needs to be read and understood at all.
Legacy code can be a pain to work with, but with a little bit of care and thought, we can make sure the code we write today doesn’t cause the same problems in the future.