Common naming conventions for option type variables and methods that return them [closed]

Question

What are some popular ways to name option type variables and methods that return option types in order to distinguish them from their non-option counterparts?

Suppose a DAO currently has a findById method that returns an instance of an entity or null, if we deprecate that method and add one that returns an option type how should we name it?

Now suppose we are refactoring code to use this new method, we don't want to replace all references to the entity variable with the option type, how should we name the option type variable?

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

I don’t think that it is a good idea having two different methods here. If in doubt about the migration, keep the old one.

But there is a way to refactor the entire code in two steps:

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 assume from your question that adapting the implementations of the interface is not an issue. Now, tell your refactoring tool to inline the old, now default, findById method.

Second, rename the method newFindById to findById.

This way you have migrated the 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 in the first place while the other code is adapted to work as before. Then, you can go through the call sites one by one and decide whether and how they should be changed. This may take some time but since the interface is already clean and the naming convention problem solved, there is no need to hurry.

Note that your example method should then rather look like:

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

Note that in both forms, the refactored old code and the new code, there is no need to name a variable of type Optional, so there’s no need for a naming convention.

The refactoring requires a Java 8 capable tool, of course.