next »

[Graham.]

I read some of your blog, interesting.

[Eniko]

Oh, looks like I forgot to address the issue, how not to give up while refactoring.

The main sentiment is: Don't do it in the first place.  You're a bad ass at working around limitations and restrictions anyway, right?  Wait till the sequel to refactor.  However, If it's a severe sticking point that will benefit you immediately then of course you do the refactor.  To keep it entertaining pick something you REALLY like to do, and reward yourself with it every N functions/methods you complete.  Yeah, it's not as productive as a coding marathon, but at least it gets done.

To squelch the little voice saying "It'll be so much easier to use if I had done it this other way", just make a note, then keep telling yourself, "I'll have time to fix it when I'm famous", and roll on about your business.

I keep wanting to agree with you but I can't, I think this is an extreme stance just like the other extreme of always refactoring everything, and will lead to horrible spaghetti code that becomes unmaintainable, hard to expand upon, and will either take far longer to create a finished product or you'll just give up.

Example: I don't often make mistakes in my design, but when I do, it's annoying. A while back I was trying to add little minimap textures to chunks of my game world. I thought of a way to do it and without going into details, it failed spectacularly. Totally not a workable solution for the issue.

But because I focussed that release on refactoring everything (yes, that was over the top, but just a personal choice) from the prior release (where I'd focussed on getting shit done) I found a new, far better place to slot that functionality after thinking about it for a few more minutes. The place I put it did not exist before I refactored.

I'm all for the getting stuff done perspective. Indies don't have time to waste creating the perfect engine. I'm all for leaving TODO notes in your code instead of doing it right the first time. But for the love of god, why wouldn't you at least refactor the code in the basic architecture that's the foundation of your game? If you build a house on a bad foundation it's going to crash, and if you build a full game on a spaghetti code foundation it's going to be about as solid as the analogous food.

[st33d]

I just refactor when I add a feature.

I'm forced to bloat the code, so now's the time to remove any previous bloat.

Thankfully FlashDevelop has some fairly good refactoring tools, so it's pretty easy to change the paradigm of the code on the fly.

[VortexCortex]

I'm all for the getting stuff done perspective. Indies don't have time to waste creating the perfect engine. I'm all for leaving TODO notes in your code instead of doing it right the first time. But for the love of god, why wouldn't you at least refactor the code in the basic architecture that's the foundation of your game? If you build a house on a bad foundation it's going to crash, and if you build a full game on a spaghetti code foundation it's going to be about as solid as the analogous food.

The short answer is because I don't need to.  I did it right the second time already:

I start out with an idea that I'm not quite sure what's the optimal way of approaching or really what will come out of it in the end.

I pick a feature and code it up in "spaghetti code", but make sure to use descriptive names and leave comments for what stuff does what.

I change and revise stuff until the feature looks interesting or I drop it.

If it's not dropped, I don't re-factor it.  I re-implement it from scratch with best practices and proper doc comments, the whole nine yards.  I use the temp noodles as a go-by, but in the remaking the code will typically gain a few other bits and tweaks, but I stick to my guns and code it "the right way", modularly.

I pick another feature and repeat.

Once it's got unit tests and all that jazz screw refactoring it unless it's a DIRE NEED, which IMHO, rarely ever rear their ugly heads...  How much did your minimaps really affect the end result, the gameplay itself?  Were they worth the refactor that created the slot? (have you released this game yet...?)

[st33d]

The main problem with, "I'll fit it later", coders is that they tend to get sacked or leave and wonder why their old employer won't have them back.

Of the few I shall name but one. Nice bloke personally, but I learned to name him The Riddler.

The Riddler would have his entire fucking code in main() or whatever he'd decided to call it that day. But you can't get into the mind of The Riddler. Oh fucking no. He's hidden code everywhere. Especially on the fucking flash timeline.

But it's a nice game. And it's impossible to do anything with it but pour bloody Bolognese sauce on it and call it a day.

As a personal plea: Please tidy up your shit as you go. I'm not asking for anally retentive alphabetic order. Just the awareness that some of your projects you will be forced to abandon half way through and some poor asshole (like me) will have to finish your job.

The Riddler as I said is personally a nice guy. I just want to cut his fucking fingers off is all.

[DelishusCake]

Theres no 'right' way to code... At least thats what I tell myself when its three in the morning and I can't deal with anymore FUCKING REFACTORING 

[Graham.]

Vortex, I get the impression you refactor more than you're suggesting.... Refactoring is always a good thing. Code dependent on messy code is slightly messier. Code dependent on that code is even worse. The higher up the chain you go, the harder life gets.

Writing a test suite for refactored code is easier. Writing custom debug tools or self-reporting stuff for refactored code is easier. Not having a test suite for a piece of code that sees heavy use today, and heavy use in the future, is generally not worth it. You lose more in covering old ground when tracking new bugs, because the test suite didn't cancel those areas out for you, than you gain from not writing tests. If you don't know how to refactor something right away, you need to wait.

The proper abstraction for a group of stuff is context-sensitive. Knowing how classes should be divided, how data should be accessed... is dependent on what else in the system would care. For example, the best function name is dependent on other function names within the same scope, the containing class's/module's role in the system, and so on. You may not understand your system well enough to pick the best name until you've developed it enough, especially around the class/function in question.

If you knew how to refactor something best when you wrote it, then it's not a critical part of your system... or you already understand the rest of the system, even though you haven't written it, suggesting that it's trivial, begging the question, why aren't you using a library or previous code? It's either that or the rest of your code isn't best tailored to the problem.... I doubt that's the case.

Maybe you mean that you find a good time to refactor once, then after that it's nit-picking? I think refactoring discussions can hinge on "how good" a refactor is in the first place. I don't consider something refactored until the parameter lists are optimal, the function names are correct, permissions are controlled (errors generate when one piece of code accesses another piece the wrong way), any sub-section can be tested independently, classes can only be seen by the right people, it's obvious how something works just by looking at it (and what it's role is relative to everything else), classes and functions are only responsible for one "thing" each.  blah blah....

I don't refactor everything perfectly. There's this slider. At 100, my code is fucked, at 0 it's clean and perfect. I try to drive it down. If something is in high use, I try to drive the slide down for it. If I encounter the pain of code who's slider is high, I take that as a good opportunity to either fix the code in question - at least in the ways that are currently relevant - or write about how it should be fixed. At some point it becomes obvious that the pain caused by a high slider is worth the cost of driving it down. Sometimes I have to go through way more pain than what should be "logically" necessary to realize this, effectively refactoring too late, but it will happen eventually.

The more people you work with, the more important a low slider becomes.

Also, I plan on using a lot of code I write for my up-coming game for future titles. I like that idea in general. It takes more planning, but it means I get increasingly better games. So refactoring is even more important.

And beyond all that, games, more than most other software projects, are subject to the highest rate of change because you're writing code to match to developing vision of a game-play experience. Someone who sees the entire game from the outset isn't pursuing their best work. Good ideas have to evolve. Flexible code drives the cost of that down. Refactoring literally buys you creative freedom.

[InfiniteStateMachine]

Just be glad we are in an age of robust refactoring tools. 

One trick I tend to use a lot is after writing a giant monolithic method I immediately look at it, try to separate it into parts and then use "Extract Method" to break it into a series of private methods. I find my future self thanking my past self fairly often for doing that.

[Graham.]

Just be glad we are in an age of robust refactoring tools. 

Amen brother. Fuck the past.

[EdgeOfProphecy]

I dunno, sometimes coding isn't the most fun thing in the world to do, but you gotta keep going through those moments.

There's a lot of enjoyment to be had in writing some real quality code.  Just remind yourself that refactoring is going to be good for your project in the long run, and helps you develop better skills as a programmer so you don't have to make as many mistakes in the future.

As for putting off refactoring as long as possible...well...there's no dogmatic test I know of that tells you "Hey it's time to refactor!"

I can write some absolute shit code that will past unit tests all day long.

Honestly, there are two reasons why you should refactor in my mind.

1)  Execution Performance:  If your game is running slow and you see that a method is consuming 70% of the CPU, it might be time to refactor it into something more efficient.

2)  Streamlining Development:  You've writting something sloppy, something bad.  It runs fine, sure, but it's going to make future development harder or maybe even impossible.  If you don't spend the 2 hours rewriting it now, it can cost you 3 weeks of time in the future because it's so hard to code around.

Number one is easy to tell.  Bust out the profiler and take a peek at what's going on under the hood.  Number two is more the "art of refactoring."  You really, seriously, though need to do it, and need to figure out when it should be done.  A nasty bit of code that introduces something stupid into your architecture can have an astounding ripple effect.  Because it's stupid, another bit of code that needs to interface with the class must do stupid things to accommodate its stupid architecture.  Before you know it, the whole program has become a dumb, tangled mess that hardly makes sense and can't be changed.

The big thing to look out for is heavy dependencies and breaches of encapsulation.  This is, in fact, why people are so big on having everything decoupled from everything else.  It's not so bad to have a class that is stupidly written internally, so long as it has a decent interface with other classes.  In this case, yeah totally weigh if it's REALLY worth it to refactor.  In this case, it's more of a "nice to have" than a "need to have."  However, if your encapsulation/dependencies are broken, then you should refactor as soon as you can before the rest of your project is damaged.

[_Tommo_]

I consider refactoring as one of the most fun things in programming
As programming is the same as solving problems in the most efficient way possible, refactoring is actually awesome, isn't it?

IMO the right time for refactoring is when you have "outgrown" your past understanding of the problem, when your objectives and how to do reach them are both clearer.
It should lead to simpler, shorter and more efficent code, less repetition of code and algorithms, less hacks and edge cases, and possibly less bugs and design flaws

So uhm, you need to refactor when you discover a better solution to something (and there's time to do it), plain and simple.

[Klaim]

I like refactoring too, and optimization too. Both for the following reason: it means I already got something that work  , and I'm just improving it!

[gnat]

I think constant refactoring has become the norm because of the sheer number of excess features in C++. Remember that Homeworld and Quake 3 were coded in C... there is no magic bullet.

Code a lot of games, get experience, think atomic/simple, design before you implement, and you simply won't need to do much if any refactoring.

[Twitch]

It's like playing golf, you go for the lowest score.

I find it fun to beat my old high score, and do the same with less than prior.

[Klaim]

I think constant refactoring has become the norm because of the sheer number of excess features in C++. Remember that Homeworld and Quake 3 were coded in C... there is no magic bullet.

If you never refactor, whatever the language, C and Python included, you're doing it wrong (or the project is very very small).

This have nothing to do with the language. I've worked with both C and Python and JavaScript. Refactoring is more like making your code clearer and possibly more generic. The language only limit the range of possibility implied by the meaning of "generic".

Also, finished products are not demonstration of future-proof code. If you just need to finish your project in a limited time, then maybe you don't have the need for refactoring. Maybe you do if that limited time is large enough and your project is somewhat complex.