Changes

Add another possible way of laying out subpackages
Line 13: Line 13:  
=== Using Subpackages ===
 
=== Using Subpackages ===
   −
Rather than clutter up a single class and package with everything, it is recommended you break your mod into subpackages.
+
Rather than clutter up a single class and package with everything, it is recommended you break your mod into subpackages. Below are a few possible methods for laying out your folder structure though you may as well come up with your own layout too.
   −
A common strategy is to make a subpackage for grouping classes that have a common purpose. For example, your blocks classes can be under <code>blocks</code>, your entities classes can be under <code>entities</code>, your helper utilities can be under <code>helpers</code>, etc.
+
* '''Group by Logic''': One possible strategy is to make subpackages for logical units of your mod. For example, if you have a block called Super Furnace you would put its block, its block entity and its item all under <code>feature/superfurnace</code>.
 +
* '''Group by Function''': Another common strategy is to make subpackages for grouping classes that have a common purpose. For example, your blocks classes can be under <code>blocks</code>, your entities classes can be under <code>entities</code>, your helper utilities can be under <code>helpers</code>, etc.
   −
It is recommended to add a <code>client</code> subpackage under your main package, to isolate your [[Sides|client-only code]] from the rest, such as your GUIs and renderers.
+
No matter how your final structure looks like it is highly recommended to add a <code>client</code> subpackage under your main package. This helps to isolate your [[Sides|client-only code]] from the rest, such as your GUIs and renderers.
    
By keeping your code in clean subpackages, you can grow your mod much more organically.
 
By keeping your code in clean subpackages, you can grow your mod much more organically.
 +
 +
{{Tip|If you are unsure on how exactly you want to structure your mod it can be a good idea to look at the source of others to see how they did it.}}
    
== Class Naming Schemes ==
 
== Class Naming Schemes ==
Line 27: Line 30:  
The usual style is to use suffixes for your classes, for example:
 
The usual style is to use suffixes for your classes, for example:
   −
* An <code>Item</code> called <code>PowerRing</code> would be in the <code>items</code> package, with a class name of <code>PowerRingItem</code>.
+
* An <code>Item</code> called <code>PowerRing</code> would have a class name of <code>PowerRingItem</code>.
* A <code>Block</code> called <code>NotDirt</code> would be in a <code>blocks</code>  package, with a class name of <code>NotDirtBlock</code>.
+
* A <code>Block</code> called <code>NotDirt</code> would have a class name of <code>NotDirtBlock</code>.
* A <code>TileEntity</code> for a block called <code>SuperChewer</code> would be in a <code>tile</code> or <code>tileentity</code> package, with a class name of <code>SuperChewerTile</code>.
+
* A <code>BlockEntity</code> for a block called <code>SuperChewer</code> would have a class name of <code>SuperChewerBlockEntity</code>.
    
== The Mod File ==
 
== The Mod File ==
14

edits