Today I was naming a package in a project which would contain code related to a concept called an "access structure".
Now, naming this package "com.myemployer.project.component.accessstructures" seems unappealing and difficult to read because of the triple "S". (The higher level packages are not actually named "project" and "component").
I was tempted to use "...component.access_structures"
I couldn't find anything mentioned in the Java conventions on Oracle's site . And a brief web search brought up nothing.
What is the official convention for names like this?
From Oracle Docs
Package names are written in all lower case to avoid conflict with the names of classes or interfaces.
Companies use their reversed Internet domain name to begin their package names—for example, com.example.mypackage for a package named mypackage created by a programmer at example.com.
Name collisions that occur within a single company need to be handled by convention within that company, perhaps by including the region or the project name after the company name (for example, com.example.region.mypackage).
In some cases, the internet domain name may not be a valid package name. This can occur if the domain name contains a hyphen or other special character, if the package name begins with a digit or other character that is illegal to use as the beginning of a Java name, or if the package name contains a reserved Java keyword, such as "int". In this event, the suggested convention is to add an underscore
Although this text doesn't specify your exact case, it does say that for an invalid package name we should use an underscore. One could argue that accessStructures is how we would define a method in Java and thus naming a package like that could be confusing.
Overall, it is really up to you.
If you want to keep with this convention, I believe you should name your package:
com.myemployer.project.component.access_structures
Also you can look up synonyms and find alternatives that would give less confusion. Some I quickly found:
accessframework
accessfactory
accessarch (accessarchitecture)
accessconstructs
I dont think there is any standard for that. People follow different naming conventions as per there convenience and readability. But most of the programmers find camel case naming as the most convenient. You can name it like accessStructure
Found one Oracle Doc which recommends to use the package name with all small letters
Package names are written in all lower case to avoid conflict with the
names of classes or interfaces.
According to docs you can't use camelCase for package naming. It's ok to use snake_case for package naming in some cases, but it is more appropriate if you can't use your domain properly, because of the hyphen sign in it or it starts with numbers. But it has to be rather an exception from the rule than the rule.
If I were you I would rephrase it. For example: accessstructures -> accesscore
Related
I tried to search on stack overflow regarding the issue I am facing but did not find any satisfactory answer. So, please read my question first and suggest.
I have a .co.in domain that I want to use to prepare packages. But as per new java conventions(?) the keyword 'in' can not be used at starting of package name. Hence, I am getting problems in building applications.
I have problem in building android application with flutter due to package name format in.co.mydomain.myapp.
The problem persists in JavaFX applications also where I am using hibernate ORM. When application is run in debug mode, I see HQL queries generated with fully qualified names of entity class resulting into in.co.mydomain.myapp.entities.Student, here also 'in' keyword is a reserved keyword of SQL queries hence it throws errors.
I need expert advice in such a horrible situation I am facing.
The whole thing works without any problem when I rename package to com.mydomain.myapp
In some cases, the internet domain name may not be a valid package name. This can occur if the domain name contains a hyphen or other special character, if the package name begins with a digit or other character that is illegal to use as the beginning of a Java name, or if the package name contains a reserved Java keyword, such as "int". In this event, the suggested convention is to add an underscore.
https://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html
So you could use in_.co.mydomain
oracle suggested that,
In some cases, the internet domain name may not be a valid package
name. This can occur if the domain name contains a hyphen or other
special character, if the package name begins with a digit or other
character that is illegal to use as the beginning of a Java name, or
if the package name contains a reserved Java keyword, such as "int".
In this event, the suggested convention is to add an underscore. For
example:
Actually this is completely theoretic question. But it's interesting why java specification don't allow uppercase characters letters in package and cause write something like this:
com.mycompany.projname.core.remotefilesystemsynchronization.*
instead of
com.myCompanyName.projName.core.remoteFileSystemSynchronization.*
Directly from Oracle Docs
Package names are written in all lower case to avoid conflict with the
names of classes or interfaces.
But it's interesting why java specification don't allow uppercase characters letters in package and cause write something like this:
The specification allows it just fine. It's only a convention to use all-lower-case.
As gtgaxiola says, this does avoid conflict with type names... in .NET naming conventions this does happen, leading to advice that you do not name a class the same as its namespace. Of course, using camelCase packages would avoid the collision entirely.
I suspect reality is that it wasn't thoroughly considered when creating the package naming conventions. Personally I rarely find it to be a problem - if I end up seeing a package with one element of "remotefilesystemsynchronization" then the capitalization isn't the main thing I'd be concerned about :)
Its just another convention - One may ask why class name always has to start with Capital or method name starts with small case and then camel-cased. Java doesn't forces you to use that way. Its just that a set of underlined rules helps huge community as Java developers to write easily understandable code for the majority who follow conventions.
No definite reason can be assigned as such. Its just what felt good and was in practice by then majority programmers while writing the convention. But yes guidelines would definitely be there before writing conventions. I don't mean its a whimsical work. Guidelines are made so that just by looking at the various elements we should be able to tell if its class, method or package - and via following conventions it has been achieved for so long now.
I've seen lots of examples like com.mycompany.someapp. Seems to be the reverse of the domain. Which actually makes sense to me.
But at the end of the day, does it really matter? We are a small shop so maybe we don't see the benefits of proper domain naming.
So, is it good practice to name it to match the domain? If so, why?
Extracted from the link to Naming a Package (Java Tutorial) in Andrew's comment: (I claim no originality or ownership of the following).
Naming a Package
With programmers worldwide writing classes and interfaces using the Java programming language, it is likely that many programmers will use the same name for different types. In fact, the previous example does just that: It defines a Rectangle class when there is already a Rectangle class in the java.awt package. Still, the compiler allows both classes to have the same name if they are in different packages. The fully qualified name of each Rectangle class includes the package name. That is, the fully qualified name of the Rectangle class in the graphics package is graphics.Rectangle, and the fully qualified name of the Rectangle class in the java.awt package is java.awt.Rectangle.
This works well unless two independent programmers use the same name for their packages. What prevents this problem?
Naming Conventions
Package names are written in all lower case to avoid conflict with the names of classes or interfaces.
Companies use [their] reversed Internet domain name to begin their package names—for example, com.example.mypackage for a package named mypackage created by a programmer at example.com.
Name collisions that occur within a single company need to be handled by convention within that company, perhaps by including the region or the project name after the company name (for example, com.example.region.mypackage).
Packages in the Java language itself begin with java. or javax.
In some cases, the internet domain name may not be a valid package name. This can occur if the domain name contains a hyphen or other special character, if the package name begins with a digit or other character that is illegal to use as the beginning of a Java name, or if the package name contains a reserved Java keyword, such as "int". In this event, the suggested convention is to add an underscore. For example:
Legalizing Package Names Domain Name Package Name Prefix
hyphenated-name.example.org org.example.hyphenated_name
example.int int_.example
123name.example.com com.example._123name
Happy coding.
Matching the domain gives you greater confidence against name collisions. It's probably more important to designers of 3rd party libraries than you and your app.
Yes, that's the suggested convention in the Java Language Specification, section 7.7.
If unique package names are not used, then package name conflicts may arise far from the point of creation of either of the conflicting packages. This may create a situation that is difficult or impossible for the user or programmer to resolve. The class ClassLoader can be used to isolate packages with the same name from each other in those cases where the packages will have constrained interactions, but not in a way that is transparent to a naïve program.
You form a unique package name by first having (or belonging to an organization that has) an Internet domain name, such as sun.com. You then reverse this name, component by component, to obtain, in this example, com.sun, and use this as a prefix for your package names, using a convention developed within your organization to further administer package names.
You don't have to follow the convention, but it's generally considered good practice. After all, suppose at some point in the future you want to release some of your code as open source - but you want to avoid naming collisions. At that point, you really ought to follow the same conventions as everyone else - and as it doesn't hurt to do so from the start...
The idea behind using domain name is to avoid namespace collisions in packaging. This only works if everyone follows the convention. So, yes, the convention is important. That said, if you never plan on exporting your code as an API or providing it to a third party, it's likely there is little downside to using whatever package name you feel like.
Practically speaking I like it for a number of reasons:
It gives users an easy place to go to just from looking at the package name
It avoids collisions between packet names (i.e. two "media" packages could be very likely otherwise)
It helps identify the same author over separate pieces of software
It keeps package names roughly the same length (ok, this is just an aesthetic point but I like it!)
As well as this, it's also recommended in the JLS. It's not a requirement, but when it's practically 0 effort to do, I'd do it unless there's a good reason otherwise.
Perhaps a better question to ask is why don't you want to follow that convention? If there's no real reason, there's no harm in following it!
The main aim is to guarantee uniqueness of package names, but if you're never going to release code for others to use then it probably doesn't matter, but there is a lot to be said for sticking with convention and worrying about the stuff that does matter. Otherwise come the day that you realise you have a great library that you want to share you could be kicking yourself for going against the flow.
Yes, it is sensible to always use a naming scheme. As a counter-example, assume that everyone would use the default package for their classes.
Common classes like User or Address would be used by several libraries, but in the end there can be only one class of a certain name in the runtime environment. (loosely speaking, it is not completely correct.)
In big projects you will likely use many external libraries, like Apache Commons, Google Guava, Spring, Hibernate, Terracotta. It's good that these libraries all use their own namespace, so that their internal classes do not accidentally conflict.
i often have in java projects a lot of small helper("storage") classes like
2-Tuple, 3-Tuple, Point, .. (think you know what i mean)
Classes that mostly only have class variables, a constructor and getters/setters.
And in my current project, i wanted to store those small classes, that are often used in a lot of other classes in the project in a seperate package. But i do not really know how to name it (my motherlanguage is not english, but code should be for english readers.)
Hope you can give me an answer on this little questions.
Greetings
:)
Different people would name these differently as the names are a matter of personal choice.
A few options:
If the storage classes conform to the Javabeans conventions, you could add the suffix "Bean" eg PointBean
I have also seen a suffix of "DO" or "VO" being used to denote a "data object" or "value object". eg PointDO
You could leave the class name as is eg Point. However if you feel that it does not convey the fact it is a storage class, try to make the package name convey that fact eg
com.xyz.valueobjects.Point
or
com.xyz.dataobjects.Point
or
com.xyz.storage.Point
Personally I like to use style #3.
I'd stick those kinds of classes in a *.util package.
I'd go with something like:
utils or the more verbose utilities
you can then break that down further if you need to:
utils.data for data-related utility classes, for example.
Additionally, there's a question here on whether to pluralise or not: Naming convention for utility classes in Java
For your information the "storage classes" you are referring to are called Java Beans. Using the popular model view controller design pattern; these would be your model. So lets say you want to put them in a package called model and the domain name of your company is mycompany.com, then the propper java naming convention would be com.mycompany.model; add this line as the first line of code (before any import statements) to all of your Java bean classes:
package com.mycompany.model;
You must also move your Java bean files into a folder structure that is the same. Lets say the file with your main method is in the directory /%ProjectHome%/, then your Java Beans go in a folder /%ProjectHome%/com/mycompany/model/
To compile these files you will now have to change to your /%ProjectHome%/ directory then type javac com/mycompany/model/*.java
Then you will be able to import these files from your other java classes by typing
import com.mycompany.model.*;
Also note, that the Java convention for package names is all lower case, as not to clash with the name space of Class names.
Hope this helps.
I believe what you're doing is using objects purely for storing data (no behaviour). And since you're talking about tuples, I assume these are used for transferring data to/from your database, so perhaps just "data objects"?
I have never understood what is the ideal way to name a project, package, class. I do it in a random way which doesn't look professional at all. I know the class name should start with a capital alphabet. But what I don't really have trouble with is finding the names that are suitable and look professional. lets consider this example. If I am writing a program for fibonacci series i give names like this:
project name = fibonacci_project
package name = org.fib.code1
class name = Code1
Doesn't look neat right? How would you do it ?
There are some tips about naming:
As you said classname have the capitalization of first letter of every word, eg. LongClassName
Sun always preferred long names that explain clearly the meaning of the class (think about DefaultTableModel). Code1 is definetely not right, maybe FibonacciCalc or something that contains Fibonacci would fit better.
Preprend Abstract if it's an abstract class
Append Impl if it's an implementation of a particular interface
Package names should start with org, com, it, etc (usually it was the backward URL of project repository or the nick of the coder)
You should split your packages according to functionality, your example is really simple so there is not a way to do it.
Think about something more complex in which you have:
org.package.gui
org.package.core
org.package.extensions
For starters, it's Fibonacci.
See Sun's java naming conventions for some details on package / class names.
Aside from that, the general rule of thumb is - all your names should be descriptive:
for class - what does it do (or what does it represent)
for package - what common functionality (goal) do all classes within that package provide (aim to achieve)
Your project name could be "fibonacci solver".
Your package could start by "com.silverkid.fibsolver"
Your main class would be "FibonacciSolver.java"
Examples:
Project name - FibonacciSeriesProducer
Package name - com.lazywithclass.utils, com.lazywithclass.entryPoint
Class name - FibonacciLogic.java, FibonacciPrinter.java
This is how I would have done it, maybe during development this will change a bit, the really important convention is naming convention for class names, see if this steps are of some help:
identifiy objects that you will need to solve the problem
Knowing what one class' purpose will be name it accordingly
Keep an eye on your class names, mantain them meaningful through the development
See here for some examples.
I like the eclipse project naming scheme, where a project name is simply the name of the core package that the project provides, e.g. Project name: org.eclipse.emf.core or org.eclipse.emf.common
Your class name should always start with Uppercase.
your package name should always start with lowercase.
and your method name inside the class should also start with the lowercase.