|
Quote: do not touch a running system.
Good advice unless it has, or is causing, lots of bugs or hindering development.
|
|
|
|
|
Greg Utas wrote: Good advice unless it has, or is causing, lots of bugs or hindering development.
I agree with that specially the second part, but (big but) only if you have someone that knows what is going in the underwears... if not, leave it running and replace it by something new, taking care that the new is covering the same functionality before replacing and having a good backup (just in case).
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I don't see any bigger problems, as long you do not need to switch from 32 to 64 bit and there is pointer arithmetics involved in the code 
Btw. 'const ref' vs. 'const pointers', I think it makes no big difference, but I can be wrong.
|
|
|
|
|
It's still a 32bit application.
The way I see it, we'll update to 128bit version before 64bit.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Update or re-write it? 
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Introducing const to a system that didn't use it, or used it haphazardly because some developers never bothered, can be quite the exercise. It's like trying to pull a shirt out of a dryer--the chain reaction can be quite messy. I've even gone down that rathole in code that I've written. "Hmm, this should probably have been const." And then giving up after lots of unexpected compile errors or deciding that mutable should be used far more sparingly.
|
|
|
|
|
You can't compartmentalize parts of it?
If you could then you create a different project/build and create a library from just that. Then the rest of the code uses that library (not the code.)
For maintenance you then decide whether to update the library (nothing else) or not. The API layer to the library would remain exactly the same during the primary update. You might update the API layer after that to make it more consistent.
|
|
|
|
|
Probably, but with difficulty.
I'm also trying to instill some modern techniques to the team without everyone going bonkers.
I'm looking for basic things that we need to do codewize to go forward into more modern ways of coding.
There's also the cost/benefit that I need to take into account and demonstrate that to the higher authorities at some point.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
have you measured for memory leaks ? if leaky code my advice replace malloc/free w/ the various smart pointers .
|
|
|
|
|
I am also working in an old C++ MFC project that was developed in the late 90's. I am using Reshaper from JetBrains. It gives a lot of suggestions when looking at old C++ code. Adding a 'const' shows up a lot. It includes a lot of suggestions to use the newer memory/string functions that require providing the buffer size. I don't take all of it's suggestions since the code is very reliable.
|
|
|
|
|
I have done this many times, doing it now for my current company. Old C code from the early 90s written to run on another OS (embedded) tweaked and tweaked into unmaintainability extreme.
At the end of each phase the programming should produce exactly the same output/changes.
My description here is for C, what I am working on now; it will work for any language(s).
Phase 1 - find and deal with global variables. This is a judgement call as some things are properly global, some are just laziness on the part of some programmer. One tactic, make a structure, move them there to get them all organized. Refer to the globals only as part of the structure and pass only pointers to the structure. Control, you want to get control of the globals or at least make it clear where they are getting changed.
In C/C++ a function that gets the structure read only will be "const", if it changes a value then not const, get it?
Phase 2 - find duplicate (or near duplicate) code and create functions or subs to perform. Replace this code with calls. I call this "mining functions', you are digging them out of the code. Repeat till there are not more easy targets to mine. You can repeat this later in the process.
Phase 3 - now look for unexecutable code - in large systems there will often be some. In the system I am working on now there were subs that never get called, functions that got called but the return values were ignored or tossed away. These really were changing global variables - that would be discovered in Phase 2, right?
Phase 4 - look for bad algorithms and processes. for loops, while loops are the first targets.
Repeat until you've done enough.
Each phase makes it easier to see what to do int the next.
|
|
|
|
|
Thanks.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
"some are just laziness on the part of some programmer"
your post is excellent advice and I suspect you have scars 
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Michael Feathers wrote a great book "Working with Legacy Code" for exactly this.
Step 1: wrap anything you are going to change in tests so you know what it does now and can ensure it continues to do that after your changes...
Step 2...whatever is necessary to fix problems you are having.
The strangler fig pattern can be helpful - gradually wrap/replace sections until the whole codebase has been replaced, like a strangler fig strangling a tree.
Ian
|
|
|
|
|
Thanks for the book reference.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
yeah, what he said. I was lazy and didn't bother to scroll to the bottom.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Changing pointers to references may have very interesting consequences. Before I'd be making API changes like that, I would want a solid set of test cases to prove I hadn't broken anything.
<sigh> - glancing at project on new laptop with 20 year old mfc code and limited comments.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Where I work that would be cost prohibitive, because of the amount of V,V & T involved.
~d~
|
|
|
|
|
ah yes IVV. The best job I despised.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Code does not rot. If it works it works. Only when it has or need to be interfaced with something new, does it need a rewrite. And by then he it may be better to write the function from scratch. Time is life. Are you willing to exchange life, yours or someone else, in order to change something that works for something that may or not work?
That said in the rare occasions. Make sure you understand the requirements and don't go into change for the sake on change.Then change what needs to be changed.
|
|
|
|
|
Thanks.
I don't think I want to change old code for the sake of change.
I just want to make it possible to steer the team towards better/modern coding practice.
Especially for new code or code that needs maintenance.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
First off, I'm not a Linux fanboi. I like to tinker with it, I've played with countless distributions, both mainstream and obscure, and have built more Linux VMs than I can remember.
For the first time ever, I'm doing an in-place upgrade right now, of Debian 11 to Debian 12, on a system I'm actually using (hosting Pi-Hole - and that's it). About a total of 8 commands, waiting, a reboot, then all good to go. Actually I'm not sure a reboot will even be necessary; I'm currently still on the waiting phase as packages are being installed...
I don't know, I can't quantify it--but I can't shake the feeling that an in-place Linux upgrade leaves the system in much better shape than an in-place Windows upgrade has ever been able to do.
Maybe it's the placebo effect. But I always feel dirty upgrading Windows, in that there's probably gigabytes worth of crap the upgrade leaves behind, that Windows has no means of thoroughly cleaning up. Yes, it keeps a WINDOWS.OLD folder, and yes, it will eventually delete it on its own over time...but it still leaves me with a nasty feeling that Linux doesn't. It's not just the disk space, but probably some stuff left running, or badly configured, that can only be avoided by wiping/repaving.
After many bad experiences over the decades, I always do clean installs of Windows. I just can't bring myself to fully trust it, even if the upgrade is entirely successful.
Am I imagining things? Is Linux truly more apt (pardon the pun) to do a better job of not leaving unnecessary crap behind?
|
|
|
|
|
well both are two different cases.. and there are differences
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
So...there's some merit to my assertion?
|
|
|
|
|
There is merit to it. Don't hold your breath to find too many Linux experts on CP tho.
Jeremy Falcon
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
