10 signs the C++ will make your life hell

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.

Two days 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 code 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 see it before it hits you:

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.

 


2 Comments

  1. Reza
    Posted 24 January 2013 at 19:21 | Permalink

    These valuable notes was exactly true, a huge amount of time needs to solve such problems that previous programmers leaves them in code.

  2. Julius
    Posted 10 September 2015 at 21:05 | Permalink

    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.