Thursday, April 19, 2007

Obscure Duplication

Many people have written about the evils of duplication in code. Refactoring tools have evolved to the point where they can often detect it. Eclipse's "extract method" refactoring will identify similar blocks of code and replace all instances with a call to the extracted method.

There are other forms of duplication in software development that are harder to find, but cause just as many problems. One common example is duplicating state between code and configuration files.

I just finished removing one such case. Fall of Rome uses rules files to define variable elements of the game, including emissary definitions. An example might be:
{ //Emissary Rank
1 //Rank
"King" //Description
}

Unfortunately, the code for determining the icons for representing the emissaries on screen relied upon static variables defined in a Java class:

public static final int kRank_King = 1

public String getIconFilename() {
switch( rank ) {
case( kRank_King )
iconName = "king"
...
}

The Emissary Rank concept is duplicated between the configuration files and the code. This makes it hard to change the Rank definitions, as I discovered accidentally when the Drow Queen I created looked like a Provincial Governor.

Fortunately, this particular instance was not hard to change. Most of the emissary descriptions are very close to the icon filenames, and I was able to replace the switch statement on emissary ranks with one line of code:

return emissary.getEmissaryRankInfo().description.toLowerCase();

4 Comments:

At 12:35 PM, Blogger Christine Salter said...

Probably a stupid question... Any chance that emissary.getEmissaryRankInfo().description might return the same value for units that should be different? Or that this convention could lead to filename conflicts with images used elsewhere in the system?

 
At 12:47 PM, Blogger carlhume said...

Not a stupid question at all. This may become an issue in an iteration or two.

In the current version the images are like Chess pieces - a rook is a rook, a bishop is a bishop, and all the pieces have their own images. We use image MASKs and custom colours to change the pieces for each player, not different images.

You do lead me to an important point - the "description" field is potentially overloaded, and this could lead to unintended side effects. Proper unit testing will minimize the impact, but this is a legacy system with poor coverage. Another level of abstraction is needed to provide the proper level of flexibility - I'll have to give it some thought.

 
At 9:05 AM, Blogger Christine Salter said...

Glad I could help! Now, if only "help" didn't mean "cause you more work"... ;-)

 
At 9:56 AM, Blogger GAME2P.COM said...

hi~ just wake by, nice site, i will come back soon to see some thing new

 

Post a Comment

<< Home