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)
You've just inherited a legacy C++ codebase, now what?
101–110 of 356 posts
Re: You've just inherited a legacy C++ codebase, now what?
#102Re: You've just inherited a legacy C++ codebase, now what?
#103I’m not sure why there’s so much focus on refactoring or improving it. When a feature needs to be added that can just be tacked onto the code, do it without touching anything else. If it’s a big enough change, export whatever you need out of the legacy code (by calling an external function/introducing a network layer/pulling the exact same code out into a library/other assorted ways of separating code) and do the res…
Re: You've just inherited a legacy C++ codebase, now what?
#104I'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".
See "git blame ignore revs file".
Intended use is exactly to ignore bulk changes like auto formatting.
Re: You've just inherited a legacy C++ codebase, now what?
#105Earlier quoted context omitted.
Yes. I switched from Python to C++ because Cython, Numba, etc. just weren't cutting it for my CPU-intensive research needs (program synthesis), and I've never looked back.
My question isn't whether it's a good fit for a specific project, I'm more interested in whether it's a good career choice e.g. can you get a job using C++ without C++ experience; how realistic is it to ramp up on it quickly; whether you're likely to end up with some gnarly legacy codebase as described in the OP; is it worth pursuing this direction at all.
Re: You've just inherited a legacy C++ codebase, now what?
#106Been there, done that. Don't be a code beauty queen. Make it compile and make it run on your machine. Study the basic control-flow graph starting from the entry point and see the relations between source files. Debug it with step-into and see how deep you go. Only then can you gradually start seeing the big picture and any potential improvements.
Re: You've just inherited a legacy C++ codebase, now what?
#107 #0: Replace the custom/proprietary Hashmap implementation with the STL version.
Once upon a time, C++ academics brow beat the lot of us into accepting Red-Black-Tree as the only Map implementation, arguing (in good faith yet from ignorance) that the "Big O" (an orgasm joke, besides others) worst case scenario (Oops, pregnancy) categorized Hash Map as O(n) on insert, etc. due to naieve implementations frequently placing hash colliding keys in a bucket via linked list or elsewise iterating to other "adjacent" buckets. Point being: The One True Objective Standard of "benchmark or die" was not considered, i.e., the average case is obviously the best deciding factor -- or, as Spock simply logic'd it, "The needs of the many outweigh the needs of the few".Thus, it came to pass that STL was missing its Hashmap implementation; And since it is typically trivial (or a non issue) to avoid "worst case scenario" (of Waat? A Preggers Table Bucket?), e.g., use of iterative re-mapping of the hashmap. So it was that many "legacy" codebases built their own Hashmap implementations to get at that (academically forbidden) effective/average case insert/access/etc. sweet spot of constant time "O(1)" [emphasis on the scare quotes: benchmark it and see -- there is no real measure of the algo otherwise, riiight?]. Therefore, the affore-prophesied fracturing of the collections APIs via the STL's failure to fill the niche that a Hashmap would inevitably have to occupy came to pass -- Who could have forseen this?!
What is done is done. The upshot is: One can typically familiarize oneself with a legacy codebase whilst paying lip service to "future maintainability" by (albeit usually needless) replacing of custom Hashmap implementations with the one that the C++ standards body eventually accepted into the codebase despite the initial "academic" protesting too much via "Big O" notation (which is demonstrably a sex-humor-based system meant to be of little use in practical/average case world that we live in). Yes, once again the apprentice has been made the butt of the joke.
Re: You've just inherited a legacy C++ codebase, now what?
#108rm -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…
Re: You've just inherited a legacy C++ codebase, now what?
#109I'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…
Re: You've just inherited a legacy C++ codebase, now what?
#110>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…
I must have missed the memo where I could just say no to basic things my boss requires of me. You know, the guy that pays my salary.