Live data from Hacker News

You've just inherited a legacy C++ codebase, now what?

gaultier.github.io

131–140 of 356 posts

Re: You've just inherited a legacy C++ codebase, now what?

#131
post #57
post #15

rm -r Problem solved

If you mean "rewrite from scratch", believe me, it is the worst thing you can do. I speak from experience, it is tempting but the few times I have done that, a few months later as I get burnt, I could only think of how an idiot who never learn I was. Legacy code is like that because it went through many bugfixes and addressing weird requirements. Start over and you lose all that history, and it is bound to repeat its…

I have been involved in a successful rewrite. It cost billions of dollars and many years when the code wasn't working so the old system was still in use. We also ended up bringing over some old code directly just to get something - anything - functional at all. For many years my boss kept the old version running on his desk because when there was a question that old system was the requirements.

Today we only have to maintain the new system (the old is no longer sold/supported), and the code is a lot better than the old one. However I suspect we could have refactored the old system in place for less time/money and been shipping all the time. Now we have a new system and it works great - but we already have had to do significant refactors because some new requirement came along that didn't fit our nice architecture.

Re: You've just inherited a legacy C++ codebase, now what?

#132

Some good advice here, and some more...controversial advice here. After inheriting quite a few giant C++ projects over the years, there are a few obvious big wins to start with: * Reproducible builds. The sanity you save will be your own. Pro-tip: wrap your build environment with docker (or your favorite packager) so that your tooling and dependencies become both explicit and reproducable. The sanity you save will be…

Step 0: reproducible builds (like you said) Step 1: run all tests, mark all the flaky ones. Step 2: run all tests under sanitizers, mark all the ones that fail. Step 3: fix all the sanitizer failures. Step 4: (the other stuff you wrote)

If we're going to visit the circles of hell, let's do it properly:

Step -1: Get it under source control and backed up.

Step -2: Find out if the source code corresponds to the executable. Which of the 7 variants of the source code (if any).

Step -3: Do dark rituals over a weekend with cdparanioa to scrape the source code from the bunch of scratched cd's found in someone's bottom drawer. Bonus point if said person died last week, and other eldritch horrors lurk in that bottom drawer. Build a VM clone of the one machine still capable of compiling it.

Yes, I have scars, why do you ask?

Re: You've just inherited a legacy C++ codebase, now what?

#133
post #116

Earlier quoted context omitted.

This is fixed by the suggestion right before it: > * Reproducible builds. The sanity you save will be your own. Pro-tip: wrap your build environment with docker (or your favorite packager) so that your tooling and dependencies become both explicit and reproducable. The sanity you save will be your own. Upgrading compiler versions shouldn't be done out-of-band with your normal PR process.

I agree that this helps, although I still think that in general, the default build should never do -Werror, since people may use other toolchains and it shouldn't surprise-break downstream (I'm pretty sure this is a problem Linux distros struggle with all the time..) If it does it only in your fully reproducible CI, then it should be totally fine, of course.

I would do wall wextra and werror. Again mostly for my own sanity. But I'd wait to add werror until they were all fixed so regression testing would continue as the warnings got fixed. Cpp_check and clang tidy would also eventually halt the pipeline. And *san on the tests as compiled in both debug and O3 with a couple compilers.

Re: You've just inherited a legacy C++ codebase, now what?

#134

create bindings and externalize function libraries for other languages, hope to your prefered deity nothing breaks

This adds additional problems. IE, Start replacing legacy C++ with Python, now debugging and following the flow of the code becomes very difficult.

If it is C++ I wouldn't think about python in most cases. Rust should come to mind. Ada, or D are other options you sometimes hear about.

Re: You've just inherited a legacy C++ codebase, now what?

#135
You need to install linters and formatters and security checkers. But you need to start using them incrementally. Trying to fix all the issues found at once is a quick recipe for madness. I suggest using clang-tidy with a meta-linter like Trunk Check

docs:

https://docs.trunk.io/check/configuration/configuring-existi...)

Re: You've just inherited a legacy C++ codebase, now what?

#136
post #17

> Rewrite in a memory safe language? like c++11 and later?

How is that memory safe? Even vector out of bounds index is not memory safe.

vector.at() is memory safe. You get a choice. Easy to ban [] if you cannot statically prove it is safe.

C++11 isn't the most memory safe language, but C++11 is a lot safer than older versions, and C++23 is better yet. I'm expecting true memory safety in C++26 (time will tell), but it will be opt-in profiles which isn't ideal.

Re: You've just inherited a legacy C++ codebase, now what?

#137
> What do you do now?

Look for another job

> You’d be amazed at how many C++ codebase in the wild that are a core part of a successful product earning millions and they basically do not compile.

Wow I really hope this is hyperbole. I feel like I was lucky to work on a codebase that had CI to test on multiple computers with WError

Re: You've just inherited a legacy C++ codebase, now what?

#138

Earlier quoted context omitted.

Step 0: reproducible builds (like you said) Step 1: run all tests, mark all the flaky ones. Step 2: run all tests under sanitizers, mark all the ones that fail. Step 3: fix all the sanitizer failures. Step 4: (the other stuff you wrote)

If we're going to visit the circles of hell, let's do it properly: Step -1: Get it under source control and backed up. Step -2: Find out if the source code corresponds to the executable. Which of the 7 variants of the source code (if any). Step -3: Do dark rituals over a weekend with cdparanioa to scrape the source code from the bunch of scratched cd's found in someone's bottom drawer. Bonus point if said person died…

I was assuming it already had unit and system tests with decent coverage. I forgot how bad stuff gets.

Maybe VM clones of various users too, and recordings of their work flows?

Re: You've just inherited a legacy C++ codebase, now what?

#139

Earlier quoted context omitted.

However you feel about this issue: It's pretty widely known that google is bad at c++. Most codebases will be of significantly higher quality.

Google chrome must be one of the most used (in terms of CPU time) C++ software in the world right now. That means it's been fuzz tested (by the developers as well as by the users and also the random websites that gives it garbage html and javascript) extensively. I can only think of the Linux kernel that is more widely used, and Linux is not C++. Since you seem to be very good at c++, can you point to a "significantl…

> Since you seem to be very good at c++, can you point to a "significantly higher quality" c++ projects please?

Not the parent commenter, but there are quite a few very high-quality C++ projects out there.

- LLVM

- KDE projects

- CMake

- Node.js

- OpenJDK

Re: You've just inherited a legacy C++ codebase, now what?

#140
post #31

Earlier quoted context omitted.

On the flip side, auto-formatting will trash your version history and impede analysis of "when and why was this line added".

I'm not hardcore on auto-formatters, but I think their impact on code history is negligible in the case of every legacy system I've worked on. The code history just isn't there. These aren't projects that used git until recently (if at all). Before that they used something else, but when they transitioned they didn't preserve the history. And that's if they used any version control system. I've tried to help teams wh…

>I think their impact on code history is negligible in the case of every legacy system I've worked on. The code history just isn't there.

Not sure if I agree here or not - whilst yes, the history isn't there, if it's a small enough team you'll have a good guess at who wrote it.

Definitely found I've learnt the style of colleages so know who to ask just from the code outline.

Post reply on HN