A lot of this assumes the codebase is testable, but most of those legacy applications rely on global state a lot...
You've just inherited a legacy C++ codebase, now what?
231–240 of 356 posts
Re: You've just inherited a legacy C++ codebase, now what?
#232Earlier quoted context omitted.
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.
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".
Re: You've just inherited a legacy C++ codebase, now what?
#233Earlier quoted context omitted.
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…
I have been involved in a successful rewrite. It cost billions of dollars and many years when the code wasn't working so the old system was still in use. We also ended up bringing over some old code directly just to get something - anything - functional at all. For many years my boss kept the old version running on his desk because when there was a question that old system was the requirements. Today we only have to…
> because some new requirement came along that didn't fit our nice architecture.
This is the thing.
I was doing the event section of the website and it was the event. I mean, it was preposterous to even think of running multiple events. Fast forward a few years, the company is now many times the size after very rapid growth, has an office in the UK and now runs multiple events. Would you have made an architecture for multiple events back then? YAGNI whispers you not to...
Re: You've just inherited a legacy C++ codebase, now what?
#234Earlier quoted context omitted.
I'm not hardcore on auto-formatters, but I think their impact on code history is negligible in the case of every legacy system I've worked on. The code history just isn't there. These aren't projects that used git until recently (if at all). Before that they used something else, but when they transitioned they didn't preserve the history. And that's if they used any version control system. I've tried to help teams wh…
SVN was a thing by the mid-2000's, and history from that is easy to preserve in git. Just how old are the sourcebases in question? (Not to shoot the messenger; just like, wow.) edit:typo
I maintain a C++ codebase that was originally written in 1996, and is mission critical for my organization. Originally maintained in Visual Sourcesafe, then in TFS source control, and now git. Some parts of it were rewritten (several times) in C#, but the core is still C++.
I was very worried when we transitioned to git that history will not be preserved and tried to preserve it, but it proved too much hassle so I dropped it.
In fact that proved not to be a problem. Well, not a problem for me, since I remember all the history of the code and all the half forgotten half baked features and why they are there. But if I'm gone then yes, it's going to be a problem. It's in a dire need for a rewrite, but this has been postponed again and again.
Re: You've just inherited a legacy C++ codebase, now what?
#235My take:
1. Source control
2. Reproducible builds
3. Learn the functionality
4. ...
If you don't understand what the code does, you're probably going to regret any changes you make before step 3!
Re: You've just inherited a legacy C++ codebase, now what?
#236Earlier quoted context omitted.
How is that memory safe? Even vector out of bounds index is not memory safe.
vector.at() is memory safe. You get a choice. Easy to ban [] if you cannot statically prove it is safe. C++11 isn't the most memory safe language, but C++11 is a lot safer than older versions, and C++23 is better yet. I'm expecting true memory safety in C++26 (time will tell), but it will be opt-in profiles which isn't ideal.
This is not idiomatic C++ in any C++ standard. You can also just replace vector with map so the brackets insert, but that isn't either.
Re: You've just inherited a legacy C++ codebase, now what?
#237> 3. Make the project enter the 21st century by adding CI, linters, fuzzing, auto-formatting, etc I would break this down: a) CI - Ensure not just you can build this, but it can be built elsewhere too. This should prevent compile-based regressions. b) Compiler warnings and static analysers - They are likely both smarter than you. When it says "warning, you're doing weird things with a pointer and it scares me", it's…
> The last step of an inherited C++ codebase is to rewrite it in a memory safe language
Simply getting rid of any actually memory unsafe C++ and enforcing guidelines will do this for you in the C++ codebase.
"Rewrite it in X" only adds complexity because it's the flavour of the month as you said in your comment.
Author is already doing the work of rewriting large chunks of the codebase in C++, they may as well follow and implement a more restrictive subset of the language, I find High integrity C++ to be good. If I can get my hands on the latest MISRA standard that is likely good as well. These may not be "required" but they specify what is enforced in . So instead of having to reskill your entire devteam on a new language which has many many sharp edges, how about just having your dev team use the language they already know and enforce guidelines to avoid known footguns.
Re: You've just inherited a legacy C++ codebase, now what?
#238Earlier quoted context omitted.
> 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.
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.
Re: You've just inherited a legacy C++ codebase, now what?
#239Earlier quoted context omitted.
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. Especiall…
C++ is super annoying in this way. Many other languages (e.g Rust) only have one compiler and good portability out of the box which completely avoids this problem. And other ecosystems that do have multiple implementation (e.g. JavaScript) seem to have much better compatibility/interop such that it's not typically a problem you have to spend much if any time on in practice.
I’ve had rust projects with strict clippy rules break when rustc is upgraded.
Re: You've just inherited a legacy C++ codebase, now what?
#240>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…
>> 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