# Dealing with my messy code

## Recommended Posts

You should rewrite your thing over and over is my solution.

Changing stuff to clean up is to much work, so make your code as messy as possible, then you cant handle it no more and rewrite all based on your earlyer work.

Skip all unused stuff, dont write code that you dont use.

Dont use any code at all is the most efficient code.

##### Share on other sites
Posted (edited)

You have to set aside good chunks of time for refactoring. The main goal is to increase code reuse. Some code can be shared between projects. Some code is repeated multiple times in your project and needs to be factored into a function with the correct arguments. It seriously helps when there is only one place you need to edit code to make "one change" in your system. Chunking your program up into classes and free functions and moving them into their own files - organizing - is a really good way to stay productive too. I once had the same problems as you and wondered if I was just unintelligent but It's been quite a few years now and I'm fairly successful I would say. Don't worry. You'll get better. A good debug output function that tells the line and file the debug statement is in helps to keep track of where code is all at as well. Use #ifdef _Debug or an equivalent to have the debug function just compile out of your program in release mode.

#pragma once
#include <string>
#include <iostream>

//if debug isn't defined, turns into a no-op
template <typename ...T>
void debug(std::string file, int line, T&& ...args)
{
#ifdef _DEBUG
unsigned int index = file.find_last_of('\\');
file[index] = '/';
index = file.find_last_of('\\', --index);
std::string finalfile = file.substr(index);
finalfile[0] = '/';
std::cout << finalfile << ":" << line << " ";
using expander = int[];
(void)expander {
0, (void(std::cout << std::forward<T>(args)), 0)...
};
std::cout << std::endl;
#endif
}

//use this, it outputs the file and line the output was made from!
#define debug(...) debug(__FILE__, __LINE__, __VA_ARGS__)

One of the simplest examples of one edit to one change in the system is a simple define for a file path string. Now if the file path changes, you can edit one bit of code to change your whole system. It's that kind of thing that will save your life and make you glad you chose to take the time to write good code.

Try to write code you can control from variables like that. It forces you to think how to make a flexible system. Take pieces of repeated code and turn them into little systems (functions) with variables (parameters) that can accomplish the task in a more abstract way. Your files will shrink and you will slowly gain the "one edit one change in the system" level of abstraction.

Another little goal I have when refactoring is to make my main function small by factoring things out of it into their own functions. E.G. my game loop goes inside a gameLoop function and my main shrinks by 50 lines. Then shrink gameLoop, factor out some stuff inside of it into a function - aiming to decrease code duplication first and foremost, but also just trying to make gameLoop smaller. Makes the program more readable. And always use good names. A good name for an out parameter that will contain an encrypted string might be "encryptedstr" but IMO encrypted_str_out will probably be better. Underscore with long descriptive names FTW.

##### Share on other sites

I've been spending a lot of time lately studying programming patterns to help myself with this problem. I like to live with by 2 policies that have helped me a lot with this. 1. Finished and imperfect is better than perfect but not finished. 2. I spend one weekend a month going through the code that I've already got working and I find places that I can clean it up. Maybe I didn't set up a few properties with proper backing fields that I could have used, maybe I see where I can use some design pattern to clean up my code. All kinds of good stuff.

##### Share on other sites
Posted (edited)
1 hour ago, ethancodes said:

Maybe I didn't set up a few properties with proper backing fields that I could have used, maybe I see where I can use some design pattern to clean up my code. All kinds of good stuff.

Speaking from experience, this approach tends to lead to over-engineered code. Refactoring doesn't mean "figure out what design pattern this most resembles and then do that," it means "simplify the code and make it easier to maintain without changing the functionality or architecture." Following design patterns in the sense that term is usually meant, especially to the letter, will not generally help with that, and may even make the code harder to understand.

I would second the calls for adding unit tests, or at least some kind of automated testing. You can actually use test-driven development to determine what an opaque piece of code does and what it depends on. The basic principle in that case is to call the code from a unit test and see what errors you get, fix all the errors, then keep adding tests of ideas you have regarding the code until you get one that fails. It's like doing science.

I find when I'm cleaning up code, my most common thought is: "do we really need this to be here where it is now?" The answer, quite often, is either "no" (in which case I can either delete it or put it somewhere else) or "yes, and that's terrible, so I'm going to restructure something so I can put this somewhere else where it's easier to follow."

Edited by Oberon_Command

## Create an account

Register a new account

1. 1
2. 2
Rutin
19
3. 3
4. 4
5. 5

• 9
• 9
• 9
• 14
• 12
• ### Forum Statistics

• Total Topics
633301
• Total Posts
3011270
• ### Who's Online (See full list)

There are no registered users currently online

×