For a client/server ECS (Entity Component System) based game, which of the below package naming style is more suitable ?
For each module, I have 3 submodule : common, server, client.
ex:
Quest module:
quest-common.jar
quest-server.jar
quest-client.jar
package naming style 1:
com.{your_company_name}.{your_app_name}.common.quest.component
com.{your_company_name}.{your_app_name}.server.quest.system
com.{your_company_name}.{your_app_name}.server.quest.service // RMI services server side
com.{your_company_name}.{your_app_name}.client.quest.view
com.{your_company_name}.{your_app_name}.client.quest.service // RMI services client side
imo, more theoretically(machine logic) logical is style 2,
but i prefer style 1 here, because its more human readable. when you work on some “component” you dont usually want go each different folder(here you have only 3 trully, there 5), but have everything under one folder.
its like modules, each module have same dirs.
but i do style 1 only in almost leaf packages, not before. thats important.
thats just my opinion.
trully you should just look what will be more readable imo. (and predict if there will be later more subpackages, because then option 1 might be more readable)
I’m in the camp of not creating packages unless there is more than 3 classes in them or there is truly an organizational requirement. On top of that, packaging trumps everything.
So if ‘quests’ are truly a separate thing then I’d put them at the root because if I’m a user of your API, I’d want to be able to look at all ‘quest’ stuff together.
Then under that server, client, view, common… and nothing else unless there are so many classes that further differentiation is necessary.
A note on this. This is only necessary when you are competing with other namespaces… ie: you intend to publish your thing as a jar used by other applications that might be including other jars that have similarly named sub-packages and classes.
And in that case, the namespace should be based on something you own… generally a domain name. So only com.{your_company_name} if you own the {your_company_name}.com domain.
Else there isn’t a strong reason to have it at all. Might as well just start with {your_app_name}.
Absolutely correct. For example, my company owns liquidcrystalstudios.com, thus our packages start with com.liquidcrystalstudios.{project_name} (yes it is annoyingly long). But I personally own tlf.io, thus my personal projects I use io.tlf.{project_name}
I do, too… but it does feel super convenient when importing app classes not to have to type com.foo.bar.baz.bing.poo.pop all the time. And a little strange. Like walking around in your underpants I guess.
Note: if you are making open source software and do not have your own domain then presumable you are pushing that code somewhere (github, for example). Perfectly fine to use that + project as your root package in that case. com.github.mycoolproject.whatever.
Take note, it does not always have to be a domain name, an example of this is the sun packages. There is no sun TLD. The same goes for my company, lots of our internal projects are lcs.{project_group}.{project_name} instead of com.liquidcrystalstudios.{...} This is because lcs is not a TLD (and not likely to ever be one). Some of my friends use their initials for example: smd.{something} It is just nice to have a package for all of your work just for organization.
It’s true. The domain thing is suggested convention as it should 100% guarantee a lack of clashing in the namespace.
…consequently, many folks will use it to try to find the source of some piece of code. (That’s why JME’s is dangerous because jme3.com has nothing to do with us.)
Actually I was using com.otm (abbreviation of OverTheMoon) just because I like it, I have had no intention to create a domain for it. Maybe I better to remove the com out of it and use otm.{my_app_name}.
hard one to get even for .io i think. 