Code Reorganization Needed #50

New Issue

2013-07-24T16:41:11Z

SenseiKiwi commented

2013-07-24 16:41:11 +00:00

(Migrated from github.com)

There are several portions of Dimensional Dungeons that are interwoven in ways that make the mod more complex. For instance, we have very large methods for importing and exporting schematics, and the export code is mixed in with other dungeon handling functions. For the sake of maintenance and sanity, we really should separate portions of the code into coherent units. Importing and exporting should be done in the same class or separate classes for each one, without any additional code involved. That is, we give these classes information on where to operate and they operate on a region of the world, and that's it. Within that code, all of the repetition needs to be refactored out. All of the loops that search for a particular block type and then perform an operation on them could be generalized.

This also touches upon rotations. Those need to be reimplemented in a way that is both efficient and manageable. I'll see what I can do about that - we can extract all the information gathered on the various metadata values by brute-forcing over all metadata values or parsing them from the code.

Code that is heavily dependent upon Minecraft's version or Forge's version must also be isolated so that maintaining support for 1.5.2 is trivial. Instead of relying on performing reverts, we should have separate copies of version-dependent classes for each MC version. Then our updates would consist of changing the common code between both versions and committing once. This might be easier said than done.

Note that in general, this is more of a reminder to myself of all the things that need to be fixed. Having a checklist, even in the form of issues, provides guidance.

There are several portions of Dimensional Dungeons that are interwoven in ways that make the mod more complex. For instance, we have very large methods for importing and exporting schematics, and the export code is mixed in with other dungeon handling functions. For the sake of maintenance and sanity, we really should separate portions of the code into coherent units. Importing and exporting should be done in the same class or separate classes for each one, without any additional code involved. That is, we give these classes information on where to operate and they operate on a region of the world, and that's it. Within that code, all of the repetition needs to be refactored out. All of the loops that search for a particular block type and then perform an operation on them could be generalized. This also touches upon rotations. Those need to be reimplemented in a way that is both efficient and manageable. I'll see what I can do about that - we can extract all the information gathered on the various metadata values by brute-forcing over all metadata values or parsing them from the code. Code that is heavily dependent upon Minecraft's version or Forge's version must also be isolated so that maintaining support for 1.5.2 is trivial. Instead of relying on performing reverts, we should have separate copies of version-dependent classes for each MC version. Then our updates would consist of changing the common code between both versions and committing once. This might be easier said than done. Note that in general, this is more of a reminder to myself of all the things that need to be fixed. Having a checklist, even in the form of issues, provides guidance.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: apex/DimDoors#50