Let’s say you’ve got a project object in your code. A project might be opened, or it might be closed. In either case, you want to register an event handler to change the status- closed projects can be opened, opened projects can be closed. Now imagine you’re Antonio’s co-worker, Grenk.

No, this time, it’s not a matter of streams. Today, it’s ternary abuse, of the “why is this even here” sort.

switch(project.getStatus())
{
    case CLOSED:
    {
        //snip: re-open the project
        break;
    }
    case OPEN:
    {
        //snip: close the project
        break;
    }
}
registerEvent(projectDB.getStatus().equals(StatusProjectEnum.CLOSED) ? TypeEventProjectEnum.ENABLED : TypeEventProjectEnum.DISABLED, project.getId(), sessionUser,
                           project.getStatus().equals(StatusProjectEnum.CLOSED) ? "Enabled project " + project.getDescription() : "Disabled project " + project.getDescription());

getDao().update(project);

Let’s trace the logic. We start with a switch on the project status. If it’s CLOSED we open it, if it’s OPEN we close it. Then, we call the registerEvent method, and use a ternary on the project status to decide what parameters to pass to the method. The result is an unreadable mess, and it’s extra confusing because we just passed by a perfectly good switch. Why not just put a call to registerEvent in each branch of the switch?

Which, by the way, is exactly what Antionio did. During the code review, Grenk objected that Antonio’s version wasn’t as “DRY” as his, but the rest of the team agreed that this was more readable.

[Advertisement] Utilize BuildMaster to release your software with confidence, at the pace your business demands. Download today!