Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

gaultier.github.io

Post reply on HN
Print view View original

121–130 of 356 posts

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

#121

Post by bluGill »

ecshafer wrote: post #12

This is pretty great advice for any legacy code project. Even outside of C++ there is a huge amount of code bases out there that do not compile/run on a dev machine without tons of work. I once worked on a Java project that due to some weird dependencies, the dev mode was to run a junit test which started spring and went into an infinite loop. Getting a standard run to work helped a ton.

The difference between greenfield and legacy code is just a few years. So learn to work with legacy code and how to make it better over time.

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

#122

Post by slingnow »

Night_Thastus wrote: post #43
mellutussa wrote: post #23

Earlier quoted context omitted.

> A one-off won't help much at all. Monumentally disagree. One-off session with a guy who knows the codebase inside out can save you days of research work. Plus telling you all about the problematic/historical areas.

I'm just stating my experience. A single day, if they still have access to the codebase might be able to clear up some top-level concepts. But the devil is in all the tiny details. What is this tiny correction factor that was added 20 years ago? Why was this value cut off to X decimals? Why didn't they just do Y here? Why do we override this default behavior? It's tens of thousands of tiny questions like that which y…

I don't understand what you're saying. Clearly both types of meetings (one-off vs recurring) would be helpful. The one-off may save you days/weeks of research, but it seems like you're not satisfied with that unless you can answer every single minor question you might have across the entire codebase.

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

#124

Post by Kon-Peki »

The article doesn't mention anything about global variables, but reducing/eliminating them would be a high priority for me.

The approach I've taken is, when you do work on a function and find that it uses a global variable, try to add the GV as a function parameter (and update the calling sites). Even if it's just a pointer to the global variable, you now have another function that is more easily testable. Eventually you can get to the point where the GV can be trivially changed to a local variable somewhere appropriate.

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

#125

Post by jchw »

eschneider wrote: post #118
jchw wrote: post #116

Earlier quoted context omitted.

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.

The scripted, packaged docker with toolchain dependencies and _is_ the build. If someone decides to use a different toolchain, the problems are on them.

Yeah that works if you are not dealing with open source. If you are dealing with open source, though, it really won't save you that much trouble, if anything it will just lead to unnecessarily hostile interactions. You're not really obligated to fix any specific issues that people report, but shrugging and saying "Your problem." is just non-productive and harms valuable downstreams like Linux distributions. Especially when a lot of new failures actually do indicate bugs and portability issues.

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

#126

Post by bluGill »

codelobe wrote: post #107

My first thing is usually: #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 imple…

In the mid 1990s when C++ was getting std::map and the other containers CPU caches were not a big deal. Average case was the correct thing to optimize for. These days CPU caches are a big deal and so your average case is typically dominated by CPU cache miss pipeline stalls. This means for most work you need different data structures. The world is still catching up to what this means.

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

#127

Post by daemin »

dataflow wrote: post #100
eschneider wrote: post #89

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)

Probably insert another Step 1: implement tests Be they simple acceptance tests, integration tests, or even unit tests for some things.

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

#128

Post by westurner »

lpapez wrote: post #104
dralley wrote: 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".

You can instruct git to ignore specific commits for blame and diff commands. See "git blame ignore revs file". Intended use is exactly to ignore bulk changes like auto formatting.

+1

  man git-blame
  git help blame
https://git-scm.com/docs/git-blame

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

#129

Post by bluGill »

professorTuring wrote: post #80

How good is AI refactoring the code? Haven’t tried it yet, but… as someone who has need to work on tons of legacy in the past… looks interesting!

Very mixed. Sometimes great, but you have too watch it close as once in a while it will do garbage.

There is a lot of non-AI refactoring for C++ these days that is very good. And many more tools that will point to areas that there is a problem and often a manual fix of those areas is "easy".

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

#130

Post by eropple »

cratermoon wrote: post #70
zer00eyz wrote: post #35

Earlier quoted context omitted.

>> It's a nice idea, but it's hard to do. One person is using VIM, another is using emacs, another is using QTCreator, another primarily edits in VSCode.. Trying to get everyone on the same page about all this is very, very hard. This is what's wrong with our industry, and it's no longer an acceptable answer. We're supposed to be fucking professional, and if a job needs to build a tool chain from the IDE up we need t…

If you're saying everyone should agree on the same IDE and personal development toolset, I disagree, sort of. The GP was suggesting the effort to add CI, linters, fuzzing, auto-formatting, etc was too hard. If that can be abandoned entirely, perhaps the legacy codebase isn't providing enough value, and the effort to maintain it would be better spent replacing it. But the implication is that the value outweighs the co…

> neither does the organization have to deal with the endless yak shaving over brace style and tool choice

I hear you, but an organization that fears this, instead of Just Pick Something And Deal With It, is an organization that probably doesn't have the right people in it to succeed at any task more arduous than that.

Post reply on HN