next »

[gnat]

I'm sure we've all been the programmer who has refactored just to use some new overhyped language feature or abstraction, that provided little to no benefit in the end anyway.

Eventually experience vastly cuts down on the amount of refactoring needed. Not to say it goes away completely for all games, but it can for smaller ones.

[Klaim]

I agree.

More: the more someone is experienced, the less consciously he refactor while coding.

[Eniko]

So to those of you who are going "just code it right the first time", I have a question. When you code your first draft, do you do it replete with all error checking and possible logging required? Cause if so, damn, kudos to you guys. I'm not that forward-thinking.

[Klaim]

I think those who say that mean:

 1. writing new code, put a lot of effort into making sure, with your current knowledge and educated instinct, that you will not need to refactor this code, or at least that it is isolated enough that you don't need to refactor anything else than this particular code.
 2. continuing working on anything else (even not coding) you will learn and get a more educated instinct and knowledge;
 3. getting back at the code written in 1, if it was simple enough, it will not need to be refactored. If you didn't know enough at the time of 1 to make it even simpler, now might be the time to refactor again.
 4. goto 1.

Experts attacking problems they never solved before know how to do this iteration in accelerated manner first in their head then in prototypes then in production code.
Non experts will not iterate yet but might have to in more slow pace, when they "have to" because the code is to hard to manage.

So yeah experience helps a lot, logic too but it's harder to maintain in you head.

[Graham.]

Yeah. I probably have to do only a few passes over a system. Often the best division of functions/data is dependent on who/what uses it. There are general principles to follow, but a lot of them have to do with the relationships between pieces of code. If you only have 1 piece of two, knowing the perfect abstraction is impossible.

However, once you have a number of dependencies established - say a few places where your new class is being used - nearly all of the information for the best refactor is there. If you need more time - as in more dependencies to exist first - to understand the nearly perfect refactor, then your new class is probably doing too much.

This means there is an upper-bound on the number of times a piece of code would need to be refactored if you're using all the available information to you each time you do.

What can happen though is that the insight that a dependency provides - say class A using the the class in question, call it STAR - may be "dirty" because class A itself isn't built in the best way. You may not realize this until you have classes Z, X, and Y using A, at which point you'll refactor A, then refactor STAR, then maybe refactor anything STAR is dependent on.

So you can get rippling refactors. The longer a piece of code stays under the weight of a long dependency chain, the better the idea that you will have of what it should be. The size of the refactor and its frequency will slowly go down in decreasing amounts.

Generally I think coders don't refactor enough, because their code becomes too complex to justify the cost of the refactor, so they hit a much lower upper bound. Either way the bound exists.

I like the previous comment. Most of my refactoring is done as I'm writing the class for the first time. Generally I write a test suite after I do something. By the time the tests are written, I've done most of the refactoring I will ever do. So that means I perform the most iterations on a piece of code in, or immediately following, the process of writing it. However the refactors I do after this point are still very important, and it would colossally bad not to do them.

As a rule of thumb it's a good idea to refactor something as soon as you can. This rule isn't always true. It's a master skill to dodge a refactor to wait for better insight, but generally the rule is true. Though I wouldn't say it is almost always true; that would be too much.

[Sir Wolf]

I'm too much of a perfectionist to let myself get away with messy code. I consider myself more of a programmer than a developer - I don't so much want to get the product done than I want to write code, and write it well.

When working for or with others, I realize that my job actually is to get the damn thing done, and that is what I do, but for hobby projects I don't resist my inner desires. I often times find myself just writing the same feature all over again in a different way, or improving (refactoring?) the current implementation rather than moving on in the development - and I don't mind! I rather enjoy it. It's probably a rather direct consequence that any of the projects I've worked on completely alone have never been finished (and I repeat, I don't mind).

It probably has to do with that I'm not immensely experienced yet and I learn new things all the time - usually learning how to better do what I just finished doing, and then I go back and do the thing with the new, better way I just learned.

Also, when I start making a game, I rapid prototype the concept at the beginning of the development, and at this stage I promise myself I won't have to use any of the prototype code if/when I decide the idea works and start working on the game. The prototypes are messy as hell, with magic constants everywhere, but they really do get done, fast, and are then promptly discarded. I'll have none of the "This was supposed to be a quick prototype so I thought I could write it badly, but hey it actually works and I don't have time and motivation to write it again well, so I'll just use this! I mean, it works, right?".

That's my mentality when I can afford it. When it's not just a hobby project for my own amusement I'll get it done, I'm not completely irresponsible, but I'm not having as much fun!

Edit: Also, I always try to check the code in in a better shape than I checked it out. This variable here could use a better name, or I have no idea what this mess here does, well I find out and tidy it up so the guy after me won't have the same headache, or this class here does too much. Small, gradual improvements.

[bateleur]

Refactoring is something I keep trying new approaches to. When I first started coding thirty years ago () I never refactored anything. Then, eventually, I had a project become so comprehensively unmanageable that there was no way I could code my way out of the hole it was in. Had it been a game I might have given up on it... but it was the software I was writing for my PhD, so that wasn't an option! On that occasion I completely rewrote it from scratch in a new language (!), but to my amazement it only took two weeks.

After that I developed a different problem: I became somewhat addicted to refactoring and my projects would overrun all the time because I was constantly redesigning them. I was mostly cured of that after spending some time in industry (not games) where constant time pressure meant refactoring was a luxury you could only occasionally afford.

Now my code architecture is generally better the first time round, but I still find myself wanting to refactor quite a bit. The rule I try to apply is: will the refactoring save time overall? (Refactoring generally makes subsequent features and debugging both easier and therefore faster.) If it won't save time, I don't do it. I usually still want to, but I'm better about resisting the temptation.

A quick note about modularity: I agree with the sentiment that modular code requires less refactoring and is generally a good plan at all times, but in fairness I think the issue is a lot more complex. Suppose, for example, that I have a very modular architecture based on object-orientation and inheritance. I might realise halfway through development that I have an object that wants to belong to two classes. After pondering multiple inheritance, mixins, components or whatever other magic my language du jour is tempting me with I eventually just conclude that the abstraction is wrong and neither object wanted to be a class in the first place. This isn't a failure to be modular per-se. It's some other kind of code-architecture failure of a kind that's not quite as easy to avoid at the design stage!

tl;dr - Modularity is only one kind of good code design. Good code design saves refactoring.

[eyeliner]

I actually like to refactor the code I type, mostly because on the first pass I do what comes out from my head without considering it is the best approach. Then, I try to simplify it, clean it.

I can spend a session only refactoring and testing, because I actually see my advancements and how next time I can do things better.

I think it's fun at times.

[Dacke]

I really like refactoring. It's all about manipulating code, which I find oddly satisfying. It's a bit like solving crosswords.