Timeline for Adding Units To Magic Numbers
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 20, 2021 at 17:34 | comment | added | tuskiomi | So why don't any time packages implement your suggestion? I've always seen constants Nanosecond, Microsecond, Millisecond, etc. with no unit, and no reference... | |
| Sep 19, 2021 at 13:16 | comment | added | KRyan | @JörgWMittag Our project called them type “tags,” and used them to great success. Of course, Java is awful about them—ours was in Typescript, where we could write a generic in four lines that could be tagged with any string, and fully compile-time compatible with any underlying type, chosen on-the-fly at the point it was needed. We even extended those flags to a very basic arithmetic suite for physical units. | |
| Sep 18, 2021 at 17:23 | comment | added | davidbak |
The issue with "magic numbers" is not when you write them: if you are calling an api with a timeout of milliseconds and you type "3" there then its because you think 3ms is just fine. The issue is troubleshooting/debugging/changing them later. How do you find the timeout that is affecting you? Search for all "3"s in a program? If you even know it is "3" and not, say, "4"? Ok, so give it a name, e.g., THREE_MS, and assume you know it is a 3ms delay you're looking for. When you find it: where do you change it and how? If you change the def'n you change all uses of it. Etc. etc.
|
|
| Sep 18, 2021 at 4:16 | comment | added | BlueRaja - Danny Pflughoeft |
If the language has a timespan class, like Java's Duration.ofMinutes(3), that would be more typesafe than an int, and remove the need to store the units in the name.
|
|
| Sep 17, 2021 at 15:30 | comment | added | somebody |
worth noting that this (semantic wrapper types) is known as newtype in FP land. and branding in TS land
|
|
| Sep 17, 2021 at 13:04 | vote | accept | Onorio Catenacci | ||
| Sep 17, 2021 at 12:52 | comment | added | leftaroundabout | @JörgWMittag actually, proper-type-hierarchy-for-physical-quantities FTW. But yeah, often stupid tiny types are sufficient and simpler to use, and with a sensibly designed language they also shouldn't introduce much boilerplate. | |
| Sep 17, 2021 at 7:28 | comment | added | René | Should tiny types be a performance or interop problem, Checker Frameworks Units Checker (or even just the Subtyping Checker) may help: checkerframework.org/manual/#units-checker | |
| Sep 17, 2021 at 6:14 | comment | added | Doc Brown | @Robyn: "unambiguous" - yes. "Nice" - quite the opposite. | |
| Sep 17, 2021 at 4:40 | comment | added | Robyn | Eric has good point. public static final MAXIMUM_TASK_DURATION_MINUTES = 3; would at least be nice and unambiguous | |
| Sep 17, 2021 at 1:01 | comment | added | Eric Duminil |
Unit should be specified somewhere. I would add // [min] to your duration definition, for example.
|
|
| Sep 16, 2021 at 17:06 | comment | added | Jörg W Mittag | Tiny Types FTW! | |
| Sep 16, 2021 at 16:10 | history | answered | Vincent Savard | CC BY-SA 4.0 |