I was just looking at some (working) code that i wrote a couple of years ago that's buried deep in my rendering engine. There was quite a few of these "solutions" that i completely forgot about. I found it pretty funny that i wrote before a particular hacky solution: "Dirty hack... fix later".

I have a kind of a todo list in my tiny slowly progressing game project, with a section for things that i should go through when something falls apart for no apparent reason.

I am afraid to type TODO in visual studio find popup.. Since its a hobby project for learning purpose, I only go back when things break.

Im doing an engine and a game, so while the game is running I dont mess with the engine, unless its just to add new stuff that I need and the engine doesnt provide.

Means the TODO comments only grows. Im telling to myself that when the game is over I will go throu all the problems I already identified and redo everything in a better way. I dont do this now cause the game is running fine, and I dont want to take a side quest with the engine and make the game break till the quest is complete.

Whenever necessary. If the "hack" gives the desired results and is just ugly for style reasons or wastes a few cycles, I don't bother with it usually. If it breaks the program, it obviously has to be fixed (with another hack )

It's different if the "hack" has influence on your program and leads to writing more hackish code (like using a global as a shortcut and then start using it throughout the program). Those should be fixed asap.

Ehmm... To be fair, so far in my latest projects, there is only one hack that comes to mind that I haven't fixed (river particle stopping code) because I'm working with the UI now.

I will come to it because the sim needs to be right for everything to look remotely good.

Now, on the UI code? I'm on the point that I'm not sure if I am writing hackish solutions or not. Funnily enough I can find out about that by saying "What if I changed Swing GUI for a SWT based one?" and then all the dependencies/fckups become clear.

If it's a hack, it isn't ready to commit.

If it's a really bad hack, I might fix it that same day or the next day, as soon as I get the hacky version functional (because once it's functional, sometimes I can see a cleaner way of doing it that I couldn't previously).

If it's a minor bit of sloppy code, and I really don't want to work on it today, I'll comment it as hacky, and later if I need to expand that function, then I'll usually rewrite the entire function with the new features and cleaner than before.

On very very rare occasions, the 'hack' is the cleanest way of doing something. I only have one of these in my current code base - a const_cast() of a string used to write to its internal buffer:

void Serialize(Serializer &serializer, std::string &value)
{
	//Serialize the string size.
	uint16_t size = value.size();
	Serialize(serializer, size);
	value.resize(size);
	
	//Serialize the characters.
	char *cStr = const_cast<char*>(value.data()); //DANGER: Hack. I'm using the .data() function of std::string to write to std::string's internal buffer.
	serializer.Serialize(reinterpret_cast<Byte*>(cStr), size);
} 

Potentially very dangerous, but almost certainly workable in major implementations of the standard library - unless the implementation decides to copy its internal buffer at every call to .data(), or unless it has a duplicate buffer for some reason, .data() should return the internal char* buffer of the std::string.

That's clean code but hacky code. I have messier code in several locations, but I don't have anything hackier than that, iirc.

I put a //TODO: *whatever there is to do* at that place in the code and I periodically Ctrl + f //TODO: to find the places where I have something to fix and as a rule I never commit if a single //TODO exists in the code.That way I'm compelled to fix them as soon as I can.Also I've made it a habit to recognize places where things have a tendency to become "tricky", basically the places that will be responsible for a lack of flexibility and the need to use some not so good method/hack and I spend extra care planning the big picture on these places, so I'm sure that everything will go as planned.I used to use a lot more hacks in the past when I had the habit of thinking as I code, but when I started to actually plan my stuff on paper, the tendency to use hacks reduced greatly.

Most programmers abhor unclean code and will naturally fix hacks if given the time (see 20% time).

But honestly, it depends on the hack. There are levels of hack from "ugh, slightly dodgy downcast here" to "mondo hackitude o rama" (thanks Microsoft ).

It also depends on the program. If it's a library that will be used by millions of users, fix the damn hack. If it's your own little project, well, it's your time... fix it or not at your discretion.

But if it's in a program that you are being paid to write, you have a financial responsibility to your employer. Do a cost benefit analysis.

• How long will it take to fix?
• How will the product be better if I fix this?
  • Will it be faster?
  • more stable?
  • will it ease future development?
• or more importantly, what are the risks of not fixing it?
  • Can the hack cause a crash?
  • or worse still.. data loss? Users will forgive a crash, but losing work (a saved game for instance) will really annoy them.

At the end of the day, you are paid to make sensible decisions about how to use your time.

Pragmatism trumps idealism every time.

My code generally starts as a list of 'ToDo:' comments, often before the project even gets a proper name.

So, 'most' of my ToDo comments get followed up on, and I can easily reach a 90+% 'finished' on the ToDo list for any given project, even if less than 20% functionality has been implemented. (Some of those ToDo entries are to create other ToDo entries that are needed to flesh out the feature's requirements.)

It might not be right, but it looks impressive if you put it all into a nice big chart.