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

301–310 of 356 posts

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

#301

Post by flykespice »

saagarjha wrote: post #247
selfmodruntime wrote: post #110

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. 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.

As others have mentioned, none of these things actually change your development workflow. But if they did, you do have the ability to say no. If your boss fails to understand that you have an environment that you're productive in, that sounds like a bad place to work.

Every company have their own workflow adapted to their tooling so that teams can work among themselves frictionless.

It's ok if you use your own tooling you are comfortable with, but you should adapt to their workflow, and the employer has no obligation to tweak their workflow to integrate your own, it's yours to adapt.

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

#302

Post by rightbyte »

mellutussa wrote: post #232
Night_Thastus wrote: post #207

Earlier quoted context omitted.

I'm saying that if you're maintaining a code base for years, a single day's explanations won't do much of anything. It's a drop in the bucket. It's not a bad thing, and it's certainly good to do, but it's not a solution to the problem.

If your granularity for a task is measured in years then you have a much different and harder problem. Effectively everything becomes a "drop in the bucket".

Having a one day intro might save you two weeks of the 6 - 36 month task of getting to know the code base.

Like ... it doesn't help that much. Mainly it saves some frustration of the build system is insane or the source code is spread out in mails, a hd and a floppy in a drawer or the current source state is broken and need to be reverted.

But if the original author is there to do a handover, the chances are the company is properly run and the work will be a breeze anyway becouse the code is good and well structured.

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

#303

Post by bluGill »

microtherion wrote: post #111
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…

> Get the code to build clean with -Wall. This is fine, but I would strongly recommend against putting something like -Wall -Werror into production builds. Some of the warnings produced by compilers are opinion based, and new compiler versions may add new warnings, and suddenly the previous "clean" code is no longer accepted. If you must use -Werror, use it in debug builds.

-Wall and -Werror should be running on all developer machines and your CI machines.

If you are delivering source code to someone else (or getting source code from someone else that you build but do not otherwise work on then you should ensure warnings are disabled for those builds. However all developers and your CI system still needs to run with all warnings possible.

The days when compilers put in warnings that were of questionable value are mostly gone. Today if you see a warning from your compiler it is almost always right.

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

#304

Post by eschneider »

cshokie wrote: post #213
dheera wrote: post #198

Earlier quoted context omitted.

> wrap your build environment with docker For microservices it is fine, but you can't always deploy everything else with docker, especially for people who want to use your app inside a docker. Docker-in-docker is a situation that should never happen. Containers are nice but they're a horrible way to pretend the problem doesn't exist. Bundle all the dependencies and make sure it doesn't depend on 5 billion things bein…

Not the OP, but I don’t think they meant that the build output is in a container. They meant that the thing you use to compile the code is in docker (and you just copy out the result). That would help ensure consistency of builds without having any effect on downstream users.

Exactly. The compiler and what ever dependencies you need _to build_ are bundled into a docker so that you don't need to worry about whatever random tools/libraries your coworkers have installed in their local environment.

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

#305

Post by SJC_Hacker »

hawk_ wrote: post #288
hobofan wrote: post #258

Earlier quoted context omitted.

> wrap your build environment with docker (or your favorite packager) so that your tooling and dependencies become both explicit and reproducable If you want explicitness and reproducibility please don't reach for Docker. Unless you take a lot of care, you will only get the most watered down version of reproducibility with Docker probably luring you into a false sense of security. E.g. pointing to mutable image tags…

> If you want explicitness and reproducibility please don't reach for Docker Is it common in C++ builds to rely on the current O/S libraries instead of say making most dependencies explicit, close to full cross-compile? Do dependencies need to be pulled in using apt-get and not something like maven?

If you care about security and bug fixes, then yes

From what I've seen the "minor version" is fixed. e.g. FROM ubuntu:22.04 and not FROM ubuntu:laatest

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

#306

Post by rayiner »

This is excellent advice, especially the list of what not to do. I don’t think it’s just C++, it’s just C++, it’s working with any legacy code base. You gotta approach it on its own terms, and analyze and fully understand what’s happening before you start changing things.

I observed from afar when the Gwydion Dylan folks (the Dylan successor to the CMU CL compiler) inherited Harlequin’s Dylan compiler and IDE and decided to switch to that going forward: https://opendylan.org. The work (done out in the open in public mailing lists and IRC) is a very nicely done case study in taking a large existing code base developed by someone else, studying it, and refactoring it to bring it incrementally into the present. They started with retooling the build system and documenting the internals. Then over time they addressed major pain points, like creating an LLVM backend to avoid the need to maintain custom code generators.

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

#307

Post by __float »

adastra22 wrote: post #238
__d wrote: post #229

Earlier quoted context omitted.

That's a feature! New warnings added to new compiler versions can identify problems that weren't previously detected. You _want_ those to -Werror when they happen, so you can fix them if they need it. Changing a compiler version is a task that has to be resourced appropriately. Part of that is dealing with any fallout like this. Randomly updating your compiler is just asking for trouble.

It is certainly not a feature because it make all infrastructure including just regular old checkout-and-build workflows break for historical versions of the code. It’s so annoying to have to checkout an older version and then have to go disable -Wall -Werror everywhere just to get the damn thing to build. Keep master clean of any warnings, for sure. But don’t put it straight into the build system defaults.

If you store the compiler version in source control, then you don't have this problem.

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

#308

Post by cljacoby »

Despite being framed as something for legacy C/C++ codebases, this is pretty good advice for setting up testing and CI automation around any project.

I recently started on a new Rust project, and despite not having to worry about things like sanitizers as much, I followed a similar approach of getting it to compile locally, getting it compile in a docker container, setup automated CI/CD against all PRs.

Although I would order the steps as 1, 3, 4, 2. Don't get out the chainsaw until you have CI/CD tests evaluating your code changes as you go.

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

#309

Post by mst »

eschneider wrote: post #101
dataflow wrote: post #100

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)

Just a note on legacy tests: Step 0.5: understand the tests. They need to be examined to see if they've rotted or not. Tests passing/failing doesn't really mean code under test works or not. The tests might have been abandoned under previous management and don't accurately reflect how the code is _supposed_ to be working.

The same applies to comments.

I have absolutely inherited codebases where one of the early steps was to make a commit excising every single comment in the code, because so many of them were old, lies, or old lies, that it wasn't worth the risk of a junior developer accidentally thinking they could be relied upon.

(and of course they remained available in history to be potentially buffed up and resurrected, but still, argh)

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

#310

Post by roland35 »

eschneider wrote: post #101
dataflow wrote: post #100

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)

Just a note on legacy tests: Step 0.5: understand the tests. They need to be examined to see if they've rotted or not. Tests passing/failing doesn't really mean code under test works or not. The tests might have been abandoned under previous management and don't accurately reflect how the code is _supposed_ to be working.

I find it helpful to try and intentionally break the code under test.

Sometimes the test still passes, and that is a good sign that something is very wrong!

Post reply on HN