General naming conventions for option type variables and methods that return them

Question

What are some popular ways to name variable names and methods that return option types to distinguish them from their non-parallel copies?

Suppose the DAO currently has a findById method that returns an instance of an object or null if we condemn this method and add one that returns the type of the parameter, what should I call it?

Now suppose we use code refactoring to use this new method, we don’t want to replace all references to an entity variable with a parameter type, what should a parameter type variable be called?

 interface Dao<ENTITY ,ID> { @Deprecated ENTITY findById(ID id); //What naming convention should we use? Optional<ENTITY> maybeFindById(ID id); } public class MyService { PersonDao personDao; public void changeAge(final Long id,final int age) { //final Person person = personDao.findById(id); //if(person !=null) //What naming convention should we use? final Optional<Person> maybePerson = personDao.maybeFindById(id); if (maybePerson.isPresent()){ final Person person = maybePerson.get(); person.setAge(age); } } 

Answer 1

If you don’t think it’s a good idea, there are two different methods here. If in doubt about migration, keep the old one.

But there is a way to reorganize all the code in two stages:

First change the interface from

 interface Dao<ENTITY ,ID> { ENTITY findById(ID id); } 

to

 interface Dao<ENTITY ,ID> { default ENTITY findById(ID id) { return newFindById(id).orElse(null); } Optional<ENTITY> newFindById(ID id); } 

I suppose from your question that adapting interface implementations is not a problem. Now tell your refactoring tool to embed the old, now default , findById method.

Second, rename the newFindById method to findById .

So you moved interface to

 interface Dao<ENTITY ,ID> { Optional<ENTITY> findById(ID id); } 

whereas all call sites have been changed from:

 Person maybePerson = personDao.findById(id); // may be null 

to

 Person maybePerson = personDao.findById(id).orElse(null); 

---

This way you have a clean interface , while other code is adapted to work as before. You can then go through the call sites one by one and decide how and how to change them. This may take some time, but since the interface already clean and the naming convention problem is resolved, there is no need to rush.

Note that your sample method should look something like this:

 public void changeAge(final Long id,final int age) { personDao.findById(id).ifPresent(person -> person.setAge(age)); } 

Note that in both forms, in the old updated code and the new code, there is no need to specify a variable of type Optional , therefore there is no need for a naming convention.

Refactoring requires a tool that supports Java 8.

Answer 2

I think this is indeed a fairly opinion-based question, since in reality there can be no authoritative or correct answer.

However, my preference is to simply name methods that usually return Optional , for example. Optional<Foo> findById(Id id) . This method is really no different from a method that can return null so that it means “no result”, except that the return type makes it more explicit.

As for the Optional variable, I usually call them as optionalFoo ... but overall I think that you name the local variable (or even the field) much less than what you call the method.