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

261–270 of 356 posts

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

#261

Post by planede »

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.

IMO there is absolutely no reason to enable warnings in CI without -Werror. Nobody reads the logs of a successful build.

If some warnings are flaky then disable them specifically. In my experience most warnings in -Wall are OK and you can suppress the rare false positives in code. Don't suppress without a comment.

edit:

Having said that there are entirely valid reasons to not have -Werror outside of CI. It should be absolutely disabled by default if you distribute source.

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

#262

Post by planede »

throwaway2037 wrote: post #174
electroly wrote: post #48

Earlier quoted context omitted.

> It's a nice idea, but it's hard to do. One person is using VIM... The things the author listed there are commonly not IDE integrated. I've never seen a C++ development environment where cpplint/clang-tidy and fuzzers are IDE integrated, they're too slow to run automatically on keystrokes. Auto-formatting is the only one that is sometimes integrated. All of this stuff you can do from the command line without caring…

> I've never seen a C++ development environment where cpplint/clang-tidy and fuzzers are IDE integrated CLion from JetBrains has clang-tidy integrated (real-time).

I assume it's clangd? It can be used from vim, vscode, ... etc as well and get a uniform IDE diagnostic experience across text editors.

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

#263

Post by planede »

keepamovin wrote: post #3

It's funny. My first step would be 0. You reach out to the previous maintainers, visit them, buy them tea/beer and chat (eventually) about the codebase. Learned Wizards will teach you much. But I didn't see that anywhere. I think the rest of the suggestions (like get it running across platform, get tests passing) are useful stress tests likely to lead you to robustness and understanding however. But I'd def be going…

You mean the guys the company laid off last week?

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

#265

Post by noitpmeder »

otabdeveloper4 wrote: post #240
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…

> every single carpenter in the world should use the exact same make and model of saw, for, uh, professionalism reasons

One person's saw literally triple checks the measurements before cutting, minimizes wastage, runs 3x faster, and is built by a company specializing in making saws.

The other saw was hand forged in a basement by the user, breaks every other day, and has a totally different blade width, and can only be used by the owner.

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

#266

Post by Joel_Mckay »

saagarjha wrote: post #254
Joel_Mckay wrote: post #21

Earlier quoted context omitted.

I've always found discussing why former employees left a project incredibly enlightening. They will usually explain the reality behind the PR given they are no longer involved in the politics. Most importantly they will often tell you your best case future with a firm. Normally, employment agreements specifically restrict contact with former staff, or discussions of sensitive matters like compensation packages. C++ i…

Note that depending on your jurisdiction discussion of compensation may be a right protected by law.

Contract law has weird consequences in different places.

Indeed, if the legal encumbrance is not legal, than its often unenforceable.

Talking with your own lawyers before doing something silly is a good habit. ;-)

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

#267

Post by rightbyte »

skipkey wrote: post #196
hyperman1 wrote: post #132

Earlier quoted context omitted.

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…

Everyone who has been around this game for long enough has scars. At one point in the early 90s I was asked to take over maintenance of a vertical market accounting app that had a few hundred users. It had been written using Lattice C, but at the time was being built with the ultra modern MS C 5.1. The first time I looked at it, I saw that the make file set the warning level to 0 and redirected the output to NUL. Rem…

Was there a warning for implicit function declaration and implicit variable type for each variable and call that used those? Or how could there be that many warnings.

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

#268

Post by nottorp »

> Most people resort to using the system package manager, it’s easy to notice because their README looks like this:

... and goes on against using system packages.

Well if you're not using what your OS provides, why don't you statically link?

After all, it's the customer who pays for the extra storage and ram requirements, not you.

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

#270

Post by rightbyte »

rfoo wrote: post #221
dataflow wrote: post #187

Earlier quoted context omitted.

I think (well, assumed) what they meant by deterministic builds was merely hermetic builds, which are easier. True determinism is overkill for step 0.

Agreed. Though in the last 6 years I've seen at least one case where truly deterministic builds mattered: A performance bug only happens when a malloc() during init was not aligned to 32 bytes, glibc on x86_64 only guaranteed 16 bytes, but depending on what alloc / dealloc happened before it may just land on 32 bytes boundary. The alloc / dealloc sequence before that point was pretty deterministic, however there were…

It is really nice to have determinatistic builds when doing estetic clean ups, to verify that the code does not change, or inspecting changes in the assembly code and limit the scope of change to just the affected code.
Post reply on HN