Faster Development

Table of Contents

Benefits

• Faster Development
• Cleaner Code
• Safe Flexibility

Setup

• Install
• Configure

Usage

• Basic
• Advanced

Self-Documenting Units

When using numeric datatypes, all units have to be spelled out in documentation, variables, and function names. Not only is this prone to human error, but it also requires significant boilerplate for what should be simple code.

/**
 * @param topSpeedMph miles per hour
 * @param floorItFeetPerSecondSquared feet per second squared
 */
data class Car(
        val topSpeedMph: Double,
        val floorItFeetPerSecondSquared: Double
) {
    /**
     * @param targetMph the target speed in miles per hour
     * @return the time in seconds
     */
    fun estimateAccelTimeSeconds(targetMph: Double) =
            // convert targetMph to ftps then divide by max acceleration
            targetMph * 1.46667 / floorItFeetPerSecondSquared
}

But, with units-of-measure, variables and functions are all documented by their type.
No more tedious documentation. No more massive variable names.

data class Car(val topSpeed: Speed, val floorIt: Acceleration) {
    fun estimateAccel(target: Speed): Time = target / floorIt
}

Better IDE Autocomplete

Additionally, units-of-measure helps your IDE make more helpful autocomplete predictions.

If we were using only doubles, the IDE would just spit out every number in scope.

// ...
val emperical = 2.4 // LaFerrari
val kunalsCar = Car(217, 31.2)
assert(kunalsCar.estimateAccelTimeSeconds(60.0) < ‸‸‸)

However, with units-of-measure, the IDE only suggests expressions (both generic and concrete) which can satisfy the rules of dimensional analysis.

// ...
val emperical = 2.4.Second // LaFerrari
val kunalsCar = Car(217.Mile / Hour, 100.Mile / Hour / 4.7.Second)
assert(kunalsCar.estimateAccel(60.Mile / Hour) < ‸‸‸)

‹ Home Install ›› Benefit: Cleaner Code ›