Naming Conventions and Package Organization Best Practices

namingorganizationpackages

I've been programming in Java, C#, Python and AS3 most of the time and in all of these languages there are packages (or something like that). The problem I found is with the naming convention, or even with the organization of the packages. I need someone to tell me WHY is this:

com.company.app.type.Object or org.authorname.project.type.Object

better than this:

app.feature.Object or app.module.Object

Another example:

Why this:

com
 +--company
     +--app
         +--events
         |   |--FeatureOneEventA
         |   |--FeatureOneEventB
         |   |--FeatureOneEventC
         |   |--FeatureTwoEventA
         |   |--FeatureTwoEventB
         |   
         +--models
         |   |--FeatureOne
         |   |--FeatureTwo
         |   
         +--services
             |--FeatureOneServiceA
             |--FeatureTwoServiceA
             |--FeatureTwoServiceB

Is "better" than this:

 company
  +--app
      +--feature
          +--one
          |   |--Model
          |   |
          |   +--events
          |   |   |--EventA
          |   |   |--EventB
          |   |   |--EventC
          |   |
          |   +--services
          |       |--ServiceA
          |  
          +--two
              |--Model
              |
              +--events
              |   |--EventA
              |   |--EventB
              |
              +--services
                  |--ServiceA
                  |--ServiceB

In the first one you have all organized by "types of objects", but the "features" are all mixed, but in the second one, the organization is by "feature" and each one has their own objects; so, you can see one feature well separated from another.

So, can anyone tell me why a lot of companies and programmers prefer the first?

Best Answer

The reason to have your reverse domain name as the beginning of a package name is to reduce the possibility of naming conflicts. This is especially important if you are writing a library or a framework. So that explains why "com" and "org" are in there.

Other then that, everyone is different and chooses their package structure differently. One reason option 1 might be better is if there is no real destinction between features or they have a lot of code that crosses over. With that, option 2 might make more sense if features really are mutually exclusive in some manner.

Also, I bet option 1 is generally the way most projects start, and then nobody ever changes it (or cares to) after. I wouldn't be surprised if a lot of companys don't put a lot of thought into their package structure anyway.

Related Topic