CODEWITHSUNDEEP
javanaming-conventionsnaming
A248
A248

Reputation: 804

Should I avoid commonly used class names?

Some class names are so "generic" that they are often found in several different packages, including in libraries and application code. Some examples:

In my IDE, attempting to auto-complete the import for a class like one of these summons several competing suggestions.

When naming classes, is it a good idea to avoid class names already used elsewhere?

For some of these examples, I would imagine that using such class name is discouraged because it is simply not meaningful enough (e.g. Factory), but I am wondering whether it is discouraged to use a class name because it is used (frequently) elsewhere.

Upvotes: 0

Views: 1130

Answers (3)

Jon Fast
Jon Fast

Reputation: 171

You should use class names where they make the most sense for you. None of the names above that you've proposed are off limits, and there's no reason why you can't use them (assuming a language that supports namespaces and can avoid naming conflicts in this way).

However, you may consider drilling down to class names that are more specific and precise, which will better describe the meaning of the objects in your code. For example:

  • Instead of Comment: LineComment or BreakComment could easily be class names in a compiler project where you would like to create semantic blocks for comments.
  • Instead of Component: ListComponent, CalendarComponent, or ViewComponent make particular sense when implementing a UI library where you have class-based components.
  • Instead of Factory: PizzaFactory makes more sense if you're trying to make pizzas!
  • Instead of Location: GeographicLocation or SemanticLocation makes more sense when implementing a directions based navigation app, and you're trying to distinguish between '45 deg N, 77 deg W' and 'next to the pizza place'.
  • Region: CodeRegion could be used in a compiler, and GeographicRegion could be used in a Maps app.

If you're afraid to be specific, namespaces and packages help. However, there is nothing discouraging you from using the same name for a class as another package where it makes sense. The class names specifically aren't copyrighted, and most IDEs now are smart enough to make distinctions between what packages you're referring to when using autocompletion.

For the most part, specificity is helpful in assisting other developers to read your code, which every developer can appreciate!

Upvotes: 2

Shadov
Shadov

Reputation: 5591

Depends if we are talking about business or technical part.

In technical part: using common names is actually a way to let others know about the patterns used, Factory is a good example - when you see a class named like SomethingFactory, you can expect a Factory Pattern. It goes further to frameworks, libraries etc. - SomethingAutoConfiguration with Spring-Boot, SomethingEntity with JPA, I think with frontend frameworks (React, Angular) Component is a really common word. So ye, by all means, use them, as long as you use them correctly.

In business part: simple, if those words describe your business domain, then by all means use them. Don't try to invent some fancy names (or thesaurus!) just because the words seem common, it's your business domain - it's sacred.

Upvotes: 0

Jason
Jason

Reputation: 5246

Comment, Region, and Location seem fine. Personally, so subjectively, Component and Factory are definitely too common to use but objectively I can't think of any conventional reason not to use them as names. I'd definitely try and couple those names with their respective usage, for example; TaskFactory, WidgetComponent, ButtonFactory, etc.

Upvotes: 1

Related Questions