Code Smell 194 - Missing Interval

From date should be lower than to date

TL;DR: Intervals are there. Why use plain dates?



  1. Create and use an Interval Object


The restriction "From date should be lower than to date" means that the starting date of a certain interval should occur before the ending date of the same interval.

The "From date" should be a date that comes earlier in time than the "To date".

This restriction is in place to ensure that the interval being defined makes logical sense and that the dates used to define it are in the correct order.

We all know it. But we miss creating the Interval object.

Would you create a Date as a pair of 3 Integer numbers? Certainly, not.

This is the same.

Sample Code


val from = LocalDate.of(2018, 12, 9)
val to = LocalDate.of(2022, 12, 22)

val elapsed = elapsedDays(from, to)

fun elapsedDays(fromDate: LocalDate, toDate: LocalDate): Long {
    return ChronoUnit.DAYS.between(fromDate, toDate)

// We need to apply this short function 
// Or the inline version many times in our code
// We don't check from Date to be less than toDate
// We can make accounting numbers with a negative number


// We reify the Interval Concept

data class Interval(val fromDate: LocalDate, val toDate: LocalDate) {
    init {
        if (fromDate >= toDate) {
            throw IllegalArgumentException("From date must be before to date")
        // Of course the Interval must be immutable
        // By using the keyword 'data'

    fun elapsedDays(): Long {
        return ChronoUnit.DAYS.between(fromDate, toDate)

val from = LocalDate.of(2018, 12, 9)
val to = LocalDate.of(2002, 12, 22)

val interval = Interval(from, to) // Invalid


[X] Manual

This is a primitive obsession smell.

It is related to how we model things.


  • Primitive


If you find software with missing simple validations, it certainly needs reification.


More Info


Code Smells are just my opinion.


Photo by Towfiqu barbhuiya on Unsplash

At any particular point in time, the features provided by our programming languages reflect our understanding of software and programming.

R. E. Fairley

This article is part of the CodeSmell Series.