Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1038185 Posts in 41953 Topics- by 33576 Members - Latest Member: Man_With_Gun

September 02, 2014, 03:37:11 AM
TIGSource ForumsDeveloperTechnical (Moderators: Glaiel-Gamer, ThemsAllTook)To refactor or not to refactor?
Pages: 1 [2] 3
Print
Author Topic: To refactor or not to refactor?  (Read 2233 times)
Muz
Level 10
*****



View Profile Email
« Reply #15 on: May 01, 2013, 09:10:25 PM »

- Remove constants from code, i.e. never have a 'int attack = 20 + dice()'. Store it as 'BASE_ATTACK = 20; int attack = BASE_ATTACK + dice()'. Just in case you tweak values later.

I've seen this overdone. If the constant is only ever used on that one line, it's perfectly clear as-is, and defining it separately is just going to muddy your code. If it's used more than once though, definitely #define it to avoid accidental bugs from changing one instance and not another.

Yeah, depends on the situation. I've overdone the whole (i + 1) -> (i + INDEX_NUMBER_FOR_THIS_THING) thing before, wasn't smart. Better to put a comment saying this is a 0 or 1 index.

But if you're sharing code, you should use constants. int attack = BASE_ATTACK + dice() is just a lot easier to understand at a glance than 20 + dice(); You can even declare the constant in the line before it, instead of up in the #define or whatever. It will act as a comment, and the compiler will optimize it anyway.



Sometimes a total rewrite makes sense, but yeah its certainly something to avoid.

If you're going to rewrite it, treat it as a different game (e.g. Spiderweb Software's Avernum vs Exile). If you're going to make a sequel, use the same engine as far as you can. Once it becomes so outdated that you can't make money or whatever, then you do a full rewrite. You're also strongly cutting down costs by reusing a 'weak' engine. Most broken engines are much easier to fix than rebuild.

And quite often by the time the engine is so cluttered up and archaic that it needs to be changed, there's a better open source alternative.
Logged
Gregg Williams
Level 10
*****


Retromite code daemon


View Profile WWW Email
« Reply #16 on: May 01, 2013, 09:36:08 PM »

Sometimes a total rewrite makes sense, but yeah its certainly something to avoid.

If you're going to rewrite it, treat it as a different game (e.g. Spiderweb Software's Avernum vs Exile). If you're going to make a sequel, use the same engine as far as you can. Once it becomes so outdated that you can't make money or whatever, then you do a full rewrite. You're also strongly cutting down costs by reusing a 'weak' engine. Most broken engines are much easier to fix than rebuild.

And quite often by the time the engine is so cluttered up and archaic that it needs to be changed, there's a better open source alternative.

Yeah thats a very good point, when it comes to games. I was admittedly thinking of internal tools when I answered. The type of thing that your going to be maintaining and updating for X years. In this area I've come across situations where its just hugely more cost effective over the long term to rebuild the tool from the ground up. That said I'd be hugely hesitant of ever re-writing a game that has a decent amount of progress.
Logged

Archendrus
Level 0
*



View Profile
« Reply #17 on: May 03, 2013, 10:13:37 PM »

Ahhh refactoring. It's so easy to be working on your game and notice something that you think could be designed or written a little better and then bam, a week or more has gone by and your game isn't any closer to being finished.  I've done it so many times.  

Refactoring can be a trap, one that I learned about the hard way...several times. So personally I don't think it's worth breaking your stride unless your code needs it because of performance issues, or it's code that your going to reuse in many projects.  If it's the second case, I wouldn't start the refactoring process until after the current project is finished.  
Logged
Gimym JIMBERT
Level 10
*****


NOTGAMER ludophile


View Profile Email
« Reply #18 on: May 04, 2013, 10:15:29 AM »

- Remove constants from code, i.e. never have a 'int attack = 20 + dice()'. Store it as 'BASE_ATTACK = 20; int attack = BASE_ATTACK + dice()'. Just in case you tweak values later.

I've seen this overdone. If the constant is only ever used on that one line, it's perfectly clear as-is, and defining it separately is just going to muddy your code. If it's used more than once though, definitely #define it to avoid accidental bugs from changing one instance and not another.

Yeah, depends on the situation. I've overdone the whole (i + 1) -> (i + INDEX_NUMBER_FOR_THIS_THING) thing before, wasn't smart. Better to put a comment saying this is a 0 or 1 index.

worse
inc(i); // Who, Me?
Logged


ILLOGICAL, random guy on internet, do not trust (lelebĉcülo dum borobürükiss)
ThemsAllTook
Moderator
Level 10
******


Alex Diener


View Profile WWW
« Reply #19 on: May 04, 2013, 01:02:18 PM »

Refactoring can be a trap, one that I learned about the hard way...several times. So personally I don't think it's worth breaking your stride unless your code needs it because of performance issues, or it's code that your going to reuse in many projects.  If it's the second case, I wouldn't start the refactoring process until after the current project is finished.  

A third, more common (for me at least), and harder to plan for case: When your code has become too brittle to work with anymore, and you'd spend less time refactoring than you would getting the code to do what you want as-is. Let a system go without refactoring for long enough, and it tends to harden to the point where it becomes impossible to change anything. There's of course no way to look into the future and see how much time you'll save from refactoring, so you just have to trust your intuition to know when it's time to do it.
Logged
Archendrus
Level 0
*



View Profile
« Reply #20 on: May 04, 2013, 09:38:34 PM »

Refactoring can be a trap, one that I learned about the hard way...several times. So personally I don't think it's worth breaking your stride unless your code needs it because of performance issues, or it's code that your going to reuse in many projects.  If it's the second case, I wouldn't start the refactoring process until after the current project is finished.  

A third, more common (for me at least), and harder to plan for case: When your code has become too brittle to work with anymore, and you'd spend less time refactoring than you would getting the code to do what you want as-is. Let a system go without refactoring for long enough, and it tends to harden to the point where it becomes impossible to change anything. There's of course no way to look into the future and see how much time you'll save from refactoring, so you just have to trust your intuition to know when it's time to do it.

True!  Something like that has to taken on a case-by-case basis.  Tough to judge what the speedier solution is.  I suppose that sort of thing comes with experience. 
Though, I've been learning the hard way that a little planning and code and code design can help one avoid getting stuck in that situation.  How the saying go? Weeks of coding can save you hours of planning? lol
Logged
Garthy
Level 8
***


Quack, verily


View Profile WWW
« Reply #21 on: May 10, 2013, 07:53:41 AM »


IF
- The current code is causing me problems, or will cause me problems, or may cause future concerns; AND
- After brief consideration I believe that the time spent refactoring will cause the total time to project completion to be reduced or quality to be proportionately increased; AND
- After spending time coming up with a mock design, it is clearly superior to the current implementation, and will save time or improve quality overall; AND
- The existing code is actively annoying me right now; AND
- I would rather solve the underlying problem than work with the existing code any longer

OR refactoring would improve the code quality AND can be done in under a couple of hours

THEN I refactor.

Rough guide. Smiley
Logged
Richard Kain
Level 10
*****



View Profile WWW Email
« Reply #22 on: May 10, 2013, 08:01:11 AM »

Yeah, refactoring is a constant temptation. Eventually you have to ask yourself, is it worth it?

I'm refactoring my current project for the third time now. The first time I was using an external library, and din't like having the dependency. The second time I used a native solution, but didn't like a lot of the work-arounds I had employ. I'm thinking this third time is going to be the charm. The solution I'm looking at seems performance-friendly, will be easy to hide behind the scenes, and will work for everything I need to do with it.
Logged
TheDrew
Level 0
**


fighting homelessness, one game at a time


View Profile WWW Email
« Reply #23 on: May 10, 2013, 03:30:21 PM »

As others before me have said, systems are worth refactoring. For instance if you give the player the ability to carry and push blocks as a core mechanic then you want to make sure that it's clean. That way you aren't constantly struggling with strange bugs and confusion when implementing different scenarios further in.
Logged
Muz
Level 10
*****



View Profile Email
« Reply #24 on: May 11, 2013, 07:59:45 PM »

Normally I do the refactoring thing in pauses between projects, like after a major version release and not being in the mood to add other features. Yeah, you shouldn't let it break your stride. But it should be done in between strides, so that you're not forced to refactor later while you're getting good momentum going along.
Logged
mychii
Level 0
***


View Profile
« Reply #25 on: May 12, 2013, 04:15:34 AM »

Usually I make notes on my previous projects (troubleshooting) and apply it for the next program/version iteration. Everything depends on the first architecture you build for the game. This is also works if you have to create the big next version, so you can take time as long as you could have to do your 'great refactoring', while also delivering new game contents in return (say on version change to 3.0 or 4.0, etc).

For example, if you make a game engine, you create it as great you could, as flexible and as loose-coupling as you could, etc2. But when it comes to the game development itself, you really have to let yourself messing the code up (after separating it from game engine codes of course). Why? Because you have to proof your concept, is your game engine architecture good enough to be messed up with when being used? When it is messed up, will the game programmers still able to twist the game if there are changes on the features as quick as they could?

The point is, you create a system so great that even if you or your team mess it up when they use it, you and your other developers can still have the flexibility to understand the code and make changes no matter how big the project is. This way, you don't even need to think of refactoring at all unless you have to integrate a new, super big system, like from single-player to multiplayer to massively multiplayer game.

You don't refactor your game logic, you refactor the system. That's why I think usually the system is done by senior/lead programmers, so that even if junior developers mess it up when using the system to create the game logic, they're still in 'safe zone' of just messing the game code instead of the system.

The system could be the game engine (which includes a lot of systems inside), AI system, inventory system, timeline, etc2.
Logged
Archibald
Level 4
****


View Profile WWW Email
« Reply #26 on: May 12, 2013, 04:40:03 AM »

My philosophy is that "refactoring is bad in general, but there are several valid exceptions" or "do not refactor unless there is a very good reason" or "if in doubt do not do it".
Logged

Europe1300 - Realistic Historical Medieval Sim
Moczan
Level 5
*****



View Profile
« Reply #27 on: May 12, 2013, 04:57:12 AM »

For personal projects I've setup a recurring, weekly task of 'maintaining codebase'. It usually means documenting last changes, but also refactoring small bits of code that were rushed. I try to keep my codebase as clean as possible to avoid huge refactor tasks that would take days or weeks.
Logged
saluk
Level 1
*


View Profile Email
« Reply #28 on: May 16, 2013, 11:52:11 AM »

Writing code and editing code are two different cognitive functions. I'm most productive when I am doing that task which most suits my current cognitive state. If I am having trouble thinking of what to add next and not feeling very creative, sometimes taking some time to clean things up that bug me free my brain to focus on new things. Similarly, going to crazy with a refactor can be draining at times, and in those moments its better to add a crazy new feature that's not too attached to whatever mess in the code is giving me a headache.
Logged
bateleur
Level 10
*****



View Profile
« Reply #29 on: May 16, 2013, 01:15:31 PM »

I refactor a lot when I'm coding unimportant things and very seldom for work stuff. The reason is simple: refactoring almost always makes your code better, but it almost never saves time.
Logged

Pages: 1 [2] 3
Print
Jump to:  

Theme orange-lt created by panic