To be honest a lot of recommendations apply to other languages as well. I.e. start with tests only then change, add autoformatting etc.
At least I had experience of applying a similar sequence of steps to a python package.
You've just inherited a legacy C++ codebase, now what?
91–100 of 356 posts
Re: You've just inherited a legacy C++ codebase, now what?
#92Earlier quoted context omitted.
Nit: The post scopes "tearing things out" to dead code as guided by compiler warnings and unsupported architectures. If going the route, I'd recommend commenting out the lines rather than removing them outright to simplify the diffs at least until you're ready to squash and merge the branch.
Better to use `#if` or `#ifdef` to prevent compilation. C & C++ don't support nested comments, so you can end up with existing comments in the code ending the comment block.
I think `#if` and `#ifdef` are not good ideas because they prevent the compiler from seeing them in the first place. A better solution is just `if (false)` which is nestable, and the code is still checked by the compiler so it won't bit rot.
Re: You've just inherited a legacy C++ codebase, now what?
#93Some 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…
I would not call that 'controversial'. In the internet days people call this behavior trolling for a reason. The punchline about rewriting code in different language gives an easy hint at where this all going.
PS. I have been in the shoes of inheriting old projects before. And I hope i left them in better state than they were before.
Re: You've just inherited a legacy C++ codebase, now what?
#94Earlier quoted context omitted.
I had that exact discussion with someone else a while ago. And when you actually go through the chromium memory bugs, it's 100% avoidable with an absolute baseline of competence and not using ancient bugs. It's unfair that C++ always has to compete in its state from 1990s against languages in their current iteration.
That's why I asked what the bar was? If Google is writing shitty C++ even with the world's eyes on their code base, who is doing it right? No one writing anything sufficiently complicated that's for sure.
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.
Re: You've just inherited a legacy C++ codebase, now what?
#95if you have access to Gemini Pro 1.5 you could put the whole code base into the context and start asking questions about architecture, style, potential pain paints etc.
Re: You've just inherited a legacy C++ codebase, now what?
#96I'd swap 2 and 3. Getting CI, linting, auto-formatting, etc. going is a higher priority than tearing things out. Why? Because you don't know what to tear out yet or even the consequence of tearing them out. Linting (and other static analysis tools) also give you a lot of insight into where the program needs work. Things that get flagged by a static analysis tool (today) will often be areas where you can tear out enti…
Yeah, I've done a fair bit of agency work dropping in to rescue code bases, and the first thing I do is run unit tests and check coverage. I add basic smoke tests anywhere they're missing. This actually speeds me up, rather than slowing me down, because once I have reasonably good coverage I can move dramatically faster when refactoring. It's a small investment that pays off.
Re: You've just inherited a legacy C++ codebase, now what?
#97I'd swap 2 and 3. Getting CI, linting, auto-formatting, etc. going is a higher priority than tearing things out. Why? Because you don't know what to tear out yet or even the consequence of tearing them out. Linting (and other static analysis tools) also give you a lot of insight into where the program needs work. Things that get flagged by a static analysis tool (today) will often be areas where you can tear out enti…
On the flip side, auto-formatting will trash your version history and impede analysis of "when and why was this line added".
I believe you can configure `git blame` to skip a specific commit. But in my experience it doesn't matter anyway for two reasons:
1. You're going to reformat it eventually anyway. You're just delaying things. The best time to plant a tree, etc.
2. If it's an old codebase and you're trying to understand some bit of code you're almost always going to have to walk through about 5 commits to get to the original one anyway. One extra formatting commit doesn't really make any difference.
Re: You've just inherited a legacy C++ codebase, now what?
#98Look, I'm not saying you should rewrite it in Rust.
But you should rewrite it in Rust.
Re: You've just inherited a legacy C++ codebase, now what?
#99>worry not, by adding std::cmake to the standard library and you’ll see how it’s absolutely a game changer I'm pretty sure my stomach did somersaults on that. But as for the advice: >Get out the chainsaw and rip out everything that’s not absolutely required to provide the features your company/open source project is advertising and selling I hear you, but this is incredibly dangerous. Might as well take that chainsaw…
> One person is using VIM, ...
I don't get your point. You know you can autoformat outside editors right? Just configure pre-commit and run it in CI. It's trivial.
> If it's an optional step that requires that they install something new (like commit hook) it's just not going to happen.
It will because if they don't then their PRs will fail CI.
This is really basic stuff, but knowledge of how to do CI and infra right does seem to vary massively.
Re: You've just inherited a legacy C++ codebase, now what?
#100Some 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)