Java – How to Handle Classes with Same Name in Different Packages

coding-standardscoding-styleconventionsjavanaming

Me and my R&D team maintain a large codebase. We've divided our business logic into multiple packages. some of which have classes with identical names.

As you can guess, the names conflict when both classes are referenced in the same Java file.

For example:

com.myapp.model (package)
 - Device (class)
 - ...

com.myapp.data (package)
 - Device (class)
 - ...

We had a debate on what's the best practice to treat these cases and the following options came up:

1st Option

Renaming the class, adding a prefix
```
ModelDevice
DataDevice
```

2nd Option

Using the full package+class name when both are referenced
```
com.myapp.model.Device
com.myapp.data.Device
```

What's more correct in terms of code management and scalability?

we are currently mixing both approaches and starting to have inconsistency

Best Answer

Use the package name. This type of problem is precisely why Java uses the package naming convention that it does. It prevents these sorts of problems, whether it's two teams in the same company or two teams on opposite sides of the earth.

Related Solutions

Use of past tense (passive voice) to connote immutability? (E.g. Array.Transposed vs. Array.Transpose)

Past-tense kinda sounds awkward. I think that you intended the word to be an adjective.

Here's my suggestion to the problem you asked for: instead of Transpose(), call it GetTransposed(). That way, you know that you are receiving something and not modifying the object.

How to deal with different programming styles in a team

I work with a team that grew from 2 developers to 10 in less than a year. I was number 3, and the first to raise a coding standards issue. The two original developers had been working side by side for a few years and they'd adopted a common standard that seemed alien to me. We had exactly the same problems you are describing.

What we did was:

Research coding standards

We spent a few days checking out established open source projects. We knew the team would expand rapidly and we were looking for real solutions based on real projects not some generic guidelines. Also we didn't care for the optimal coding standards, but for a set of rules and guidelines that would make sense and not call for the refactoring of all of our codebase. We were looking for a coding standards hack if you will.

The three of us decided that the best coding standards out there for an established PHP project were those followed by Zend Framework. Fortunately the Zend Framework people provide a very comprehensive coding standards document.

Creating our own coding standards

Of course applying another project's coding standards on our project as is didn't make sense. We use the Zend Framework document as a template:

First we removed everything that didn't apply to our project
Then we changed everything that we perceived as a matter of style to our style
And finally we wrote everything down

So we had a fairly large document at our hands, stored in our fancy wiki, it was a nice read, agreed upon by all of us. And completely useless on its own.

Staying true to our promise

Our codebase at the time was about 1*10^6 sloc. We knew that since we adopted formal coding standards we had to start refactoring our code, but at the time we were pressed with other issues. So we decided to just refactor our very core libraries, a mere 5*10^3 sloc.

We assigned one of us to be the coding standards master (we used local profanity in place of master) with the responsibility of checking and enforcing the standards. We recycle the role every few sprints. I was the first, and it was a lot of work, as I had to monitor almost every commit.

We had several new discussions and small addendums to the original document during my tenure, and finally we had a somewhat stable document. We change it every now and then but most of these changes are on new features of the language, as PHP 5.3 was a major release in all but name.

Dealing with the new guy

When the next new guy arrived, it was time to put our coding standards to the test. After a small introduction to our codebase, we asked him to evaluate our coding standards document. He almost cried. It appeared that he did everything differently.

As I was the coding standards master at the time, it was up to me to evaluate his input and revise the document accordingly. His proposals were:

Matters of personal style (summarily dismissed)
Standards that made sense to his Java background but no so much with PHP (dismissed)
Conventions that he carried from his brief exposure with PHP (some were dismissed, but a lot proved to be popular conventions that we never thought of or found out in our initial research)

For the next couple of weeks he was assigned a simple task: Bring several parts of our codebase up to date with the standards. I had to carefully choose those parts based on a few rules:

Code should be relatively easy for someone unfamiliar with our codebase (and PHP in general)
Code should be on what he was hired to do

I monitored his process and he did a fine job. We identified several parts of code that was impossible to fit our document and revised accordingly (code and / or standards, whichever made more sense)

And then another new guy arrived. We repeated the process (different master this time), and it worked again. And again.

In conclusion

Create a coding standards document, but make sure that your standards are not exclusively your own but do reflect common standards in the wider community of your platform.
Assign a similar role to our coding standards master. Someone to monitor at least new code, and especially new code from new members. Recycle the role, as it's extremely boring.
Always evaluate input from a new member. Always revise your standards if it makes sense. Your coding standards document should be evolving, but slowly. You don't want to re-refactor your codebase at each iteration.
Allow for some time for each new member to learn and adapt to your standards and conventions. Learn by doing works best in these situations.
Wiki works wonders for such documents.
Code reviews work wonders for any situation!

At some point in the process it was suggested that we use a pre-commit hook to automate checking of the standards. We decided against it for a variety of reasons, there are some interesting discussions on StackOverflow on the issue:

SVN automatic code formatting on check in?
Version Control and Coding Formatting
PHP codesniffer (phpcs) - how to allow override when using as part of a svn pre-commit hook?
SVN Pre-commit hook to be triggered for a particular folder
Implementing PHP Coding Standards

Some are PHP specific, but the answers apply to all platforms.