What would be the best way to clean up a code base

Here’s a quick guide on cleaning up your codebase:

Work In Modules

When you first sit down to start cleaning up, it’s going to feel overwhelming. It’s difficult to decide where to start. The simple answer is, at the top. Start with the first file and work your way down.

In each file, it can be helpful to temporarily add some returns in to make it easier to see where one block of code ends and another begins. This will also prevent you from accidentally deleting something you needed.


Delete, Don’t Comment

Some devs are guilty of what I call method hoarding. Remember that awful code you wrote three months ago, for a legacy version of the app, that no longer does anything and is utterly useless?
Yeah, you don’t need that anymore.
There’s no need to comment it out if you know there’s no need for it. Just get rid of it. If you really want to save it, create a graveyard file outside of the working directory where you can save all your old code. Be sure to notate what file it originated from, what it’s use was, and when it was removed.

Test Often

Editing code is not the same as editing english. It’s easy to remove something important without even realizing it. Every time you finish a file or make a big change, Testing the code that pertains to that. Unit tests are best, but if you don’t have those then manual testing will suffice.

Follow the Style Guide/Stay Consistent

Pretty much all major languages have a standard style guide. Google it and use it. It will save a lot of time and rescue you from having to make tough styling choices. Plus, if you bring on another dev to look at your code, it will be much more familiar to them and they will already know how to style it (assuming they are a good developer and know the style guide).
The key with style guides is to stay consistent. If you run into a situation not covered by the style guide for whatever reason, document it and keep the styling consistent across all other instances.
You should also have a layout for file naming, file structure, git commits, and pull requests. Document all of that and again, stay consistent!

Cleaning Is Not Refactoring

Don’t refactor while you’re cleaning. Refactor while you’re refactoring!
Cleaning the codebase is purely stylistic. It’s making your code easier to read relative to the way it’s laid out in the IDE. While this is also an affect of refactoring, the goal of refactoring is to make your code more efficient, which has nothing to do with cleaning.

This also means you can’t rename things. Renaming things in your code is an extremely risk game, especially if you have a large codebase. Do your best to get the name right the first time. If there’s a name that’s really bothering you, put it in the backlog until you realize you’ll never have time to fix it and eventually accept it as an ugly quirk of your code (which you can later use as a topic to bitch about when you’re having beers with your coworkers).

The usual reason to compile methods into a library is because of reuse. You have common functionality that is used by many applications and you only want to have one source.
If this application is legacy the code might not be used anywhere else.
As I don't know what the code looks like, it is difficult to know why you want to split up the code.
Maybe the design does not have a good structure? If that is the case, you can start to create new classes that improves the structure, but the source code is compiled with the main application.

If you want to make sure that the code is not broken after a change, you should create test cases for the part you are changing. And of course you do that before you make any changes.
To write and use test cases is a lot of work, but in the end of the day it might save you from expensive bug.

TEST CASE Fundamentals[^]
How to write effective Test cases[^]

First of all, this is a bad idea.

But if you are going to do it anyway, do some serious reading up on unit testing. For unmanaged C++, have a look at CPPUnit at Sourceforge.