{
  "id": 9680718,
  "title": "Normalize Units at the Boundary, or Ship a 12x Bug",
  "url": "https://urgent.news/2026/09/25/normalize-units-at-the-boundary-or-ship-a-12x-bug",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-25T02:39:54.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/ruixuan_jiang_663eb75f3fa/normalize-units-at-the-boundary-or-ship-a-12x-bug-5f72"
  },
  "original_language": "en",
  "account": "A user inputs a number into a depth field labeled in inches. However, your formula mistakenly assumes the input is in feet. You shipped a 12x error, and the type system failed to catch it because both values are merely numbers. From experience, I stopped trusting unit labels and made the conversion a type-level concern instead. Choose a single internal unit, such as feet, and convert everything at the boundary. For a US-customary-focused calculator, feet is a natural choice. Export conversion factors into the canonical unit. Downstream code will never see a unit again, so there is only one place where a unit can be incorrect - a table of five constants that you can easily verify. This also provides you with a free Unit type. Validate the unit, not just the number. The converter should reject an unknown unit and a non-positive dimension, clearly naming the field. The unit check in the units object may seem redundant when the parameter is typed Unit, but the validated state comes from persisted, parsed JSON, where the type annotation is merely a claim. Export a function to convert the string value to a number, checking for an empty string, non-finite numbers, and considering zero as a special case. Not every numeric field is a measurement. For instance, a count of beds, slabs, or retaining walls should be an integer. Use a separate validator for such cases. When dealing with shapes, the geometry should be concise enough to keep inline. Each shape branch will differ by one or two lines. For a circle, length represents the diameter, while for a triangle, width represents the perpendicular height. The label must change accordingly, as the meaning of the input changes. Keeping the label as \"width\" for a triangle is problematic, as users might enter the slant height instead. The final guard ensures that the volume is finite and non-zero, preventing any unusable values from slipping through.",
  "summary": "A user types 3 into a depth field. The label says inches. Your formula assumes feet. You just shipped a 12x error, and nothing in the type system noticed, because both values are number . I hit this class of bug repeatedly while building material calculators, so I stopped trusting unit labels and made the conversion a type-level concern instead. One canonical unit Pick a single internal unit and…",
  "key_points": [
    "User inputs depth in inches, but formula assumes feet",
    "Convert all inputs to a single internal unit at boundary",
    "Validate unit and number, reject unknown or non-positive values"
  ],
  "editors_take": "Treating unit conversions as a type-level concern and validating units at the boundary reduces errors and provides a clear, single source of truth for unit correctness in code.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}