10 Signs The C++ Will Make Your Life Hell (Legacy Code)
This post contains affiliate links that help support my writing at no cost to you. Thank you x.
You think it’s going to be great. There are subtle signs it isn’t…
There’s an exciting new task on the horizon. You’re really looking forward to getting your teeth into something new. The morning finally arrives when you get to sit down and take a look at your new charge. Oceans of lovely C++ code, untouched by anyone for months, maybe years, and now it’s all yours. You dream of the efficiency improvements you will make, of the features you’ll be able to add that will make you look like the department coding superstar. Yes – this project is going to be the making of you.
A week later, you’re pounding the desk in frustration as yet another attempt to improve a class or function doesn’t work quite as you expected. What small changes you have managed to make leave you with a feeling of uncertainty since the program is crashing intermittently and you have a suspicion that your changes might be the reason.
There’s no documentation, you can’t understand the endless layers of complexity, and the whole thing seems to have been written by someone who wanted to deliberately obfuscate everything they were doing. Your manager is asking questions about timescales and suddenly you realise your predicament for what it is:
LEGACY CODE HELL!
Here are 10 signs to help you recognise legacy code hell:
1. There are more than fifteen class header includes at the top of each .h file, and an additional five that are commented out.
2. Some classes contain methods that are thousands of lines long.
3. All the variables have tiny names, like “i”, “n” and “_kl”.
4. The ghosts of programmers past have written unanswered questions instead of comments in the code: “//Is this a call for registering??”
5. A base class has overloaded the ++ operator, so it does more than just ++.
(It takes you three days to work this out, as the effect is so subtle you start to think you are actually going mad before you stumble upon the root of the problem)
6. Coupling and dependence is so high, every time you change anything the program segfaults when you run it.
7. Code is obviously copied and pasted between lots of different cpp files that all do a similar, but not-quite-the-same, thing.
8. Everything is mutexed to within an inch of its life.
9. The code is compiled without -Wall.
10. You turn on -Wall and get 532,764 warnings.
What Can You Do About It?
If you’re lucky enough to find yourself working on a legacy code monster, take heart. There is nothing more perfectly crafted to improve your programming skills than working on complicated, old, highly coupled and obscure code. If you need guidance or just some commiseration from someone who understands, then this book is absolutely brilliant. I have a copy in my desk. Also worth a read is the absolute unfailing classic, Dealing With Legacy Code by Michael Feathers.
Have fun!
These valuable notes was exactly true, a huge amount of time needs to solve such problems that previous programmers leaves them in code.
you can write bad code in any language
1. that’s normal, I think
2. lammer wrote 🙂
3. i = iterator, n = size, convention, if red-black tree is named i, lammer wrote
4. that lammer was poet
5. overloaded operators could be very useful, when good used, your fault, you should learn c++ before
6. lamer wrote (there are techniques to avoid segfaults – e.g. set each pointer to NULL when freed to avoid double free, …) or lammer edited 🙂
7. bad design
8. mutexes are mutexes …
9. this is definitely fault of c++ language 🙂
10. same
It’s not very good to start learning c++ on some semifinished project, mainly badly written.
I saw horrible things written by man definitely learning lanuage directly on his project.