Jump to content

  • Log In with Google      Sign In   
  • Create Account


How often do you revisit your hacky solutions or "ToFix" comments?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
27 replies to this topic

Poll: How often do you revisit your hacky solutions or "ToFix" comments? (47 member(s) have cast votes)

How often?

  1. Always (13 votes [27.66%])

    Percentage of vote: 27.66%

  2. Sometimes, when i have the time (19 votes [40.43%])

    Percentage of vote: 40.43%

  3. Pretty much never unless it finally breaks (15 votes [31.91%])

    Percentage of vote: 31.91%

Vote Guests cannot vote

#1 Waaayoff   Members   -  Reputation: 780

Posted 17 October 2013 - 07:10 AM

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".


"Spending your life waiting for the messiah to come save the world is like waiting around for the straight piece to come in Tetris...even if it comes, by that time you've accumulated a mountain of shit so high that you're fucked no matter what you do. "

Sponsor:

#2 Waterlimon   Crossbones+   -  Reputation: 2416

Posted 17 October 2013 - 09:06 AM

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.


o3o


#3 Icebone1000   Members   -  Reputation: 1012

Posted 17 October 2013 - 09:37 AM

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.


Edited by Icebone1000, 17 October 2013 - 09:37 AM.


#4 froop   Members   -  Reputation: 636

Posted 17 October 2013 - 03:09 PM

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 tongue.png)

 

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.



#5 TheChubu   Crossbones+   -  Reputation: 3933

Posted 17 October 2013 - 03:32 PM

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.


"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

 

My journals: dustArtemis ECS framework and Making a Terrain Generator


#6 ApochPiQ   Moderators   -  Reputation: 14617

Posted 17 October 2013 - 03:37 PM

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



#7 Servant of the Lord   Crossbones+   -  Reputation: 17910

Posted 17 October 2013 - 04:24 PM

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.


It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.

[Fly with me on Twitter] [Google+] [My broken website]

All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.                                                                                                                                                            [Need web hosting? I personally like A Small Orange]
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal


#8 Sock5   Members   -  Reputation: 162

Posted 17 October 2013 - 04:45 PM

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.


>removed<


#9 ChaosEngine   Crossbones+   -  Reputation: 2218

Posted 17 October 2013 - 05:06 PM

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 biggrin.png ).

 

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. 


Edited by ChaosEngine, 17 October 2013 - 08:50 PM.

if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight

#10 Luckless   Crossbones+   -  Reputation: 1729

Posted 17 October 2013 - 06:04 PM

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.


Old Username: Talroth
If your signature on a web forum takes up more space than your average post, then you are doing things wrong.

#11 Icebone1000   Members   -  Reputation: 1012

Posted 17 October 2013 - 06:14 PM

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 biggrin.png ).

 

Didnt Bill Gates said he prefer lazy ppl because they find ways to do the work faster and easier?



#12 ChaosEngine   Crossbones+   -  Reputation: 2218

Posted 17 October 2013 - 07:27 PM

 

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 biggrin.png ).

 

Didnt Bill Gates said he prefer lazy ppl because they find ways to do the work faster and easier?

Dunno if Gates said that, but I'd agree with it.

To paraphrase Terry Pratchett "it takes a lot of work to be truly lazy".


if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight

#13 Petter Hansson   Members   -  Reputation: 587

Posted 17 October 2013 - 08:10 PM

I usually put down //TODO: and //POSSIBLE TODO: in my code. The former is generally something I will revisit as it's part of developing the functionality I've been assigned to do - I just need my brain to focus somewhere else for a moment. The //POSSIBLE TODO: category (that I might sometimes abbreviate to //TODO: stupidly enough) are things that at some undefined point in the future might become relevant to change. I rarely end up revisiting these.

 

Also have //HACK: and //NOTE: tags to warn for and explain WTF-code. Not using these nearly as often, for obvious reasons.


Edited by StubbornDuck, 17 October 2013 - 08:15 PM.


#14 cardinal   Members   -  Reputation: 810

Posted 17 October 2013 - 08:58 PM

The only time I commit hacks is when we're up against a deadline, the fix is localized and the proper fix requires tons of testing to a bunch of systems. I generally have a proper fixed shelved in perforce for when the game is safe to commit these changes to again.

 

I often find myself fixing a lot of other engineers' TODO's. Often when tracking down bugs I'll debug down to the problem only to find a comment stating: "TODO: you need to do blah or it will break when blah happens"

 

I do sometimes leave TODO comments when I want to revisit an existing implementation later on when I have more time, but these aren't usually hacks, just not extensible in the way I'



#15 Bacterius   Crossbones+   -  Reputation: 8272

Posted 18 October 2013 - 06:40 AM

When the number of "todo" comments crosses some arbitrary threshold - which varies in space-time, aka the "I gotta fix this mess" effect - I focus on getting them down to a sane level before continuing to add more features, if I have time (e.g. no imminent deadline or priority feature to implement). I eventually get around to it for projects I really care about. Eventually.

 

Well, it depends, of course. If it's things like "todo: improve this later on to support XXX" then I would probably implement it immediately after implementing said XXX out of necessity, unless I found a better alternative in the meantime. If it's a "todo: this could be better", that can wait (possibly indefinitely). If it's a "todo: [insert pseudocode]" then it's obviously just a placeholder to give high-level structure to my code until I actually get around to writing it. I try only to submit working and elegant code to the world, with as little todo's, missing bits and warnings (and free of as many bugs as possible) but sometimes nothing else will do in the time given, and you just gotta put that hack in to make the thing work like you want it to..


Edited by Bacterius, 18 October 2013 - 06:46 AM.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#16 tmccolgan88   Members   -  Reputation: 253

Posted 18 October 2013 - 05:23 PM

I wind up doing this with most pieces of code I write that require more than a little bit of thought.  My first pass I code with the sole goal of getting whatever I'm trying to do working. Usually by the time it does work the eloquent, or at least not awful, solution presents itself.



#17 slicer4ever   Crossbones+   -  Reputation: 3300

Posted 18 October 2013 - 06:21 PM

it depends, does the "hack" save me several days worth of re-writing code?  Then i can live with it.  however, if i forsee re-doing things to be structured in a better format, and it would save me future work, i'll go back and redesign things if i need to.

 

 

 


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.

 

out of curiosity, why didn't you call c_str() instead?


Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.

#18 Paradigm Shifter   Crossbones+   -  Reputation: 5203

Posted 18 October 2013 - 06:40 PM

c_str is probably more likely to copy the data to put a null terminator on it? He's writing to the string not reading it. That code isn't going to null terminate the string which may violate an assumption the class makes (unless the null terminator is included in the size count). That code looks pretty dodgy to me.

 

 

If you read the whole data file into memory beforehand it's probably better to just construct the string from the raw bytes in the file buffer.

 

I'd just overload Serializer::Serialize to take a string argument though I think. Presumably it knows how to read bytes from the file so I'd read however many is needed then construct the string from the buffer.


"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#19 Servant of the Lord   Crossbones+   -  Reputation: 17910

Posted 18 October 2013 - 11:02 PM

out of curiosity, why didn't you call c_str() instead?


.data() gets a char* string that is equivalent to the data the std::string holds. (pre-C++11)
.c_str() gets a null-terminated char* that is equivalent to the data the std::string holds.

This means that an implementation is more likely to create a copy of the string data for a call to c_str()... in theory. In practice, they almost certainly return the same string pointer.

In C++11, .data() is also required to be null-terminated. So they are even more almost-certainly going to be the same string pointer. Because of this, I chose the one the more closely documented my intent: I wanted to access the internal buffer (the 'data').
 

c_str is probably more likely to copy the data to put a null terminator on it? He's writing to the string not reading it. That code isn't going to null terminate the string which may violate an assumption the class makes (unless the null terminator is included in the size count).


.data() in C++11 is guaranteed to be null-terminated, just like c_str(). Since it's already null-terminated when I get the buffer (".........\0"), and I'm not writing over the terminator, the end result is still null-terminated..
 

That code looks pretty dodgy to me.

Absolutely. tongue.png  That's what this thread is for, right? wink.png 
It's pretty much the only true "hack" I have in my code - I have a few messy functions, but no other 'hacks'.
 

If you read the whole data file into memory beforehand it's probably better to just construct the string from the raw bytes in the file buffer.
 
I'd just overload Serializer::Serialize to take a string argument though I think. Presumably it knows how to read bytes from the file so I'd read however many is needed then construct the string from the buffer.

Yea, that would be ideal. I wish I could just hand std::string a null-terminated char* buffer for it to take ownership of, and that I could take() ownership of it's own null-terminated char* buffer (with the std::string then becoming an empty string, similar to move-semantics).

 

The problem with overloading Serializer::Serialize() for a string argument, is the std::string still won't take ownership of the char* buffer you'd read the data into - a completely unnecessary copy of every string read will always take place for no reason, unless you write directly to the string's buffer.

 

I should actually use &str[0] to get a non-const pointer to the internal data... oops. That'll let me avoid the const_cast, but it'll do the same thing anyway. Really, they ought to just make .data() return a non-const pointer. rolleyes.gif


Edited by Servant of the Lord, 18 October 2013 - 11:04 PM.

It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.

[Fly with me on Twitter] [Google+] [My broken website]

All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.                                                                                                                                                            [Need web hosting? I personally like A Small Orange]
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal


#20 Orymus3   Crossbones+   -  Reputation: 6837

Posted 19 October 2013 - 09:03 AM

I alway refactor/fix my shit unless its in code i havent visited in months (thats legacy code then lol)




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS