Please put units in names | Hacker News Reader

Please put units in names

ruudvanasseldonk.com

1,284 pointstodsacerdoti594 comments

Built-in unit types are underrated. F# has them. Other languages should seriously consider adding them, despite the fact that feature bloat is a serious language problem and they're relatively niche: they are that useful, and I honestly don't think they would interfere much with other features.

Something like:

    unit type Meters = m
    unit type Seconds = s

    function sleep(time: Int[s]): void

    val speed = 5.4 m/s // Type = Float[m/s]
    val distance = parseFloat(prompt('enter time')) * 1 m // Convert unitless to meters just by multiplying
    val time = distance / speed // Type = Float[s]
    print("${time}") // Prints "# s"
    print("${time / 1 s} seconds") // Prints "# seconds"

    val complexUnit = 7 * 1 lbf/in2 // 7 lbf/in2
    // != 7 psi (too hard to infer) but you can write a converter function
    function toPsi<N : Numeral>(value: N[lbf/in2]): N[psi] {
        return value * 1 psi*in2/lbf
    }

It requires extending number parsing, type parsing (if the brackets aren't already part e.g. in TypeScript), and extending types to support units of measurement at least if they are statically known to be subtypes of `Numeral`.

Naming variables with their units doesn't solve the issue of mis-casting and using units incorrectly, and newtypes are too inconvenient (and sometimes impossible without affecting performance) so nobody uses them. Even as a very software-focused programmer I encounter units like seconds, bytes, pixels, etc. all the time, they are almost never newtypes, and I get bugs from forgetting to convert or converting incorrectly.

Yup, I have been using branded types in TS to avoid similar issues, and I still do miss F# units of measure.

Even though branded types prevent assignment of values with invalid units, opaque types are inferior in that the compiler doesn't know the relationship between the types (as exemplified in the parent comment) and you need a slew of helper functions & casting.

I just realized that you could probably do a decently complex unit algebra (at least to the basic level of F#'s unit of measure support) using the unit strings as brands and Typescript's template string types to match them. I'm not sure if that's a good idea or not in practice, but after seeing Wordle done with template string types I'm more certain than ever it is possible to do some interesting things with it.

I use a variant of branding in TS for this too, but it’s very much shoving semantics into the language that aren’t meant to be there. Subclasses of primitive types would be semantically closer to F#, but at the expense of being able to ever treat the values as values

In C++ units can, and often are, implemented on top of the existing type system.

See std::duration/time_point specifically for times, and boost.units for generalized unit support.

It is implemented via (templated) wrappers, but they are very close to zero overhead if not completely free. User defined literals also allow for a very succinct syntax, but to be honest, I usually don't bother. I normally write:

    auto delay = std::chrono::seconds{3};

instead of:

    auto delay = 1s;

Using templates I once implemented logic for dealing with SI units[1]. I also included angles, which is a bit odd but useful in practice.

It is really nice to have a type system that checks your formulas. Saved me a couple of times.

[1] https://gitlab.com/roeles/zen/-/blob/master

In C++ you can use user defined literals to make the units stuff compile time checked, similar to this https://github.com/bernedom/SI for example.

My Ti-89 has this. It's actually really useful because I don't always remember the magical ways units fit together and it solves and simplifies the units for me.

Long before that, very flexible units management was seen on HP-28 then HP-48 series.

So from your example I understand that F# doesn't know how to do more complex unit conversion? Does it know N=kg m/s^2 for example? That's related to the issue I often encountered with unit types. They work great for simple use cases, and give you a sense of security, but then fail and you end up writing lots of code just to make the unit types happy (you might argue that it makes the code safer, but it can be a lot of time spend). One cthing that falls over in pretty much all implementations I've encountered is log units (dBm, dBW,...)

> Does it know N=kg m/s^2 for example?

F# does if you tell it, i.e.:

   [<Measure>] type kg = g
   [<Measure>] type m
   [<Measure>] type s
   [<Measure>] type N = kg * m / s^2

Although, of course, in practice you'd probably just use whatever's defined in https://fsharp.github.io/fsharp-core-docs/reference/fsharp-d...

Not for log units tho.

Can someone break this down for me? val speed = 5.4 m/s // Type = Float[m/s]

I understand that the speed variable is automatically assigned a type of Float[m/s] based on the m/s there, but I'm confused about how the units are just placed at the end of the value assignment: val speed = {value} {unit}

Is this just a F# property that units can be added at the end of value assignment, and F# interprets them as units correctly?

Also, anyone know of methods for incorporating units as types in Python? It would be great to have an equivalent method as demonstrated here, where dividing types automatically creates a new type unit, and perhaps even associates with a related type, i.e: type(kg / (m * m * m)) == density

I think the syntax for expressions was extended to allow a `<unit expression>`, with or without angle brackets, at the end of any numeric expression. They're erased at compile time, so at runtime or via reflection you can't inspect the dimensions of a value. The only value of the units - which isn't insignificant - is the compile time checking.

Unfortunately the same isn't as easily done in Python:

1. You would need to reify these units as actual constants with overridden operators to track values, and some wacky (if even possible) mypy type shenanigans.

2. The types aren't erased and so would impact the performance of any critical code. F# isn't quite used in high frequency trading, but it does target numeric heavy users like those wanting to write scientific workloads, and units help improve correctness there. But if the types are computed at runtime and not erased, it would be an enormous hit to performance.

Unless you can figure out some way to get "3.0 * m" to be a plain old datatype (float) in Python while still retaining type info in mypy/pylance/pyrite. Perhaps there's a way, but I'm not sure.

Edit: This Python library seems to be trying to solve for these issues! https://pint.readthedocs.io/en/0.10.1/

I'm not sure if they've actually solved the runtime performance problem, but I suppose as long as you're not doing unit assignment/conversion in a loop, it should be fine.

your example is a bit confusing because you mislabeled the prompt for distance in

    val distance = parseFloat(prompt('enter time')) * 1 m // Convert unitless to meters just by multiplying

See https://unyt.readthedocs.io/en/stable/ in Python. This sort of feature fits really well within Python's featureset.

In the land of JavaScript, one could implement unit types as a babel plugin.

Going from "could" to actually doing it are two very different things, however.

I don't see how you'd go about doing this. Babel doesn't have a type checker, and for type level features you'd need support from typescript.

So you need a typescript plugin - however the typescript compiler api (which btw is not officially supported) is not flexible enough to support new type syntax (for things like m/s) so you'd a fork.

I used to work at a company with two database fields, speed_kmph.

The documentation read "speed_kmph - This field contains the travelling speed in MILES PER HOUR - please do not be confused by the name".

Woo, great job guys.

DB field names can be really hard to change. All those crystal reports to update, and the sales managers pet access DB that the hero set up for him that you don’t know about.

>DB field names can be really hard to change.

I find it really hard to accept any excuse for something like that. It's why enterprise code is so sloppy, people doing the most expedient thing rather than what is correct.

This is why it's dangerous to encode the unit in the variable, because it will eventually change (we had code that was measured in seconds and had to be changed to measure in 20/ths of a second for more granularity, if the timer variable had been named "timer_seconds" it would have had to be changed everywhere.

If you change the unit, I think the variable should be changed everywhere.

It's hard to know what assumptions code is making and by forcing you to change the code everywhere (which should be pretty easy in any modern IDE) you at least have a chance to evaluate any issues that unit change could cause.

Someone doing a half-assed refactor doesn't mean it's "dangerous" to encode a unit in a variable or function.

I do agree that generally it's better to use something like a struct that's more flexible, but doing that for every function is also quite verbose. For some functions the time requirement may never change as well.

In this specific case, it seems like creating a new property with the new data in a new name would be the safest path forward. Ensuring the unit are in both property names will prevent confusion.

This sounds like a feature to me and modern IDEs make this type of simple refactoring quite straight forward for most languages.

It's even better when the documentation gets stale too. And now this is in meters/second but the name implies km and docs specify miles.

recently I was looking at some pcap parsing code which was storing the timestamp field into a timeval structure (that nominally has usec precision), but then treating it as nanoseconds (as pcap supports both resolution). It made for some very confusing reads!

Java and Kotlin have a nice Duration class. So in Kotlin you can do

  delay(duration = Duration.ofMinutes(minutes = 1))

which is equivalent to

  delay(timeMillis = 60_000)

Using the optional argument names here for clarity; you don't have to of course.

Sticking with the JVM, a frequent source of confusion is the epoch. Is it in millis or in seconds? With 32 bit integers that has to be seconds (which will set you up for the year 2038 problem). However, Java always used 64 bit longs for tracking the epoch in milliseconds instead even before the year 2000 problem was still a thing. Knowing which you are dealing with is kind of relevant in a lot of places; especially when interfacing with code or APIs written in other languages with more 32 bit legacy.

Things like network timeouts are usually in milliseconds. But how do you know this for sure? Specifying, them in seconds means that there's less risk of forgetting a 0 or something like that. So, using seconds is pretty common too. You can't just blindly assume one or the other. Even if you use the Duration class above, you'd still want to put the magic number it takes as a parameter in some configuration property or constant. Those need good names too and they should include the unit.

The Duration.ofMinutes thing doesn't address the exact same problem. Anyone can put the units on the "right side". You don't even need a fancy "Duration.ofMinutes" helper function. Clarity-wise that's not different than just putting a comment saying how long it is and what units. The problem in the article is getting the units on the "left side," which, yes, you have to put the units in the name of the function.

Ah no. The function accepts a `Duration` type which could be precisely 1 m 23 s 14 ms 10 us 8 ns. And so you don't need `delay_ms` vs. `delay_ns` or anything because the type encodes the precise duration. If you passed a nanosecond `Duration` into `delay` it will delay ns, if you pass a millisecond `Duration` it will delay ms.

You have to enforce the units within the function, but that’s not the same as putting them in the name of the function.

For example, in Erlang, the sleep function could/should have been written to take named tuples: `timer:sleep({seconds, 3})`

Go has time.Duration type as well and works like this:

time.Sleep(10 * time.Millisecond)

The Go compiler is also happy with time.Sleep(1000), which the new "expert full stack" dev just PR'd.

To me Durations are a zero sum gain, because in this case they hide relevant detail (int64 nanoseconds) without enforcing usage. Compare it against what Golang could easily provide -- time.SleepMilli(100), which is 40% less characters for my aging eyes to parse than time.Sleep(100 * time.Millisecond).

After all, in the very same package we have a unit in the name:

   t := time.Time{}
   t.UnixMilli() // 1647952024456

    timeout = timedelta(seconds=300)
    frobnicate(timeout)

Working with GCP or Azure's Python SDK is like navigating a jungle of types. Some calls return a `compute_engine_list_item` while others return a `compute_engine` type and these are difficult to inspect and reason about, because Python classes default to printing something along the lines of `<__main__.myclass at 0x7fa8864a1040>`, making heavily typed Python code quite difficult to work with.

No paradigm is going to save you from spaghetti-code, but being able to pass a list and get an integer in return, makes it very easy to reason about what you can do with these values, whereas it can be quite difficult to reason about custom types/objects.

My point is, that knowing if `frobnicate(timeout=300)` is in seconds or minutes can be just as difficult (or even more difficult) as knowing what specific object I need to instantiate and pass to `frobnicate` (in the above case a `timedelta`)

> being able to pass a list and get an integer in return, makes it very easy to reason about what you can do with these values

I disagree; to paraphrase Ian Malcolm: what you can do with these values is less important than what you should do with these values. For example, we can add a distance to a currency, if they're both int or float; that doesn't mean we should.

The most obvious example of this is "stringly-typed programming", where pretty much everything is "string". Can I append a user-input string to an SQL statement string? Sure; but I shouldn't. Can I append a UserInput to an SQLStatement? Not without conversion (i.e. escaping)!

In general you're right.. strong typing needs good tooling and thourough language support to be fun. Python is a bit lacking in both of these.

In this specific example i disagree, timedelta is part of the standard library and should be widely known and familiar.

Badly designed type systems should not be the measuring stick.

But in your example above, typed Python would instruct your editor and tools like mypy to flag any improper use of frobnicate. You can set up your editor to offer you a tip on what type to use as soon as you type in `frobnicate(`.

In cases where typing is not really available, I prefer to put types into APIs instead of variable names (and Python makes that great: `frobnicate(duration_as_timedelta=timeout)`).

I do not think the fact that Google API’s have terrible types is a good argument against typing in general.

When I dealt with the Azure SDk for Python I frequently wrote small scripts that created the types in question and then called breakpoint() so that I could examine the types interactively.

Fully agree with everything in this article. This is definitely a code smell to me to see unitless sizes and intervals specified. I know that whenever I’m doing a code review and I see some property or variable name like “timeout” or “size” I will ask the developer to change the name to make it clear what the unit is trying to portray.

When possible, I also encourage the use of better types than simple integer values, (like TimeSpan if .NET) as these further reduce ambiguity and the potential for mistakes.

This is such a simple thing to find and fix but it definitely helps in the long term.

I also agree but would offer a third suggestion - add the type to the function name as well, so you see this line in code: `timeoutSec(timeout)`. You can't enforce people to name the parameter correctly, this means that anyone reading doesn't have to go digging to know the parameter type. Also stuff like `timeoutSec(timeoutMs)` stands out like a sore thumb.

> I know that whenever I’m doing a code review and I see some property or variable name like “timeout” or “size” I will ask the developer to change the name to make it clear what the unit is trying to portray.

In a dynamic language, maybe.

In a static language, especially Haskell/Scala/Ocaml/F#, I hate duplicating the type.

I would go one step further and suggest that all physical quantities should either have the units in the identifier name or encoded in the type system. Meters, seconds, milliamps, bytes, blocks, sectors, pages, rpm, kPa, etc. Also it's often useful to explicitly distinguish between different unit qualifications or references. Seconds (duration) versus seconds-since-epoch, for example. Bytes versus page-aligned bytes, for another.

Having everything work this way makes it so much easier to review code for errors. Without this means that as a reviewer you must either trust that the units and conversions are correct or you should do some spelunking to make sure that the inputs and outputs are all in the right units.

100%. This is a baseline requirement where I work. If you don't either include the units in the identifier name, or use the type system where possible, your code is not getting merged.

The only people I've ever met that think this is unnecessary are also the same people that ship a lot of bugs for other people to fix.

> The only people I've ever met that think this is unnecessary are also the same people that ship a lot of bugs for other people to fix.

I find feelings about this depend a lot on how much ceremony the type system involves; and just how many units and references to them there are in the system.

Asking bash coders to write "sleep 5s" instead of "sleep 5" - I doubt you'd get any objections at all.

But if you're putting a foo.bar.Duration on a getDefaultTimeoutFromEnvironment on a setConnectTimeout on a HttpRequest on a HttpRequestInitializer on a NetHttpTransport on a ProviderCredential to make a simple get request? People who've come from less ceremony-heavy languages might feel less productive, despite producing 10x the lines of code.

What type of industry/product do you work in/on? And what sort of languages do you work in?

What does a type for ‘seconds’ do that an ‘integer’ doesn’t?

I may be misunderstanding this.

I _really_, _really_ like F#'s 'unit of measure': https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...

This. I really miss it when working outside of F#. I work on scientific code bases with a lot of different units and have been burned by improper conversions. Even with a high automated test coverage and good naming practices, such problems can go undetected.

It's a big omission that it doesn't support fractional units. These come up in things like fracture mechanics for stress intensity.

God I love F#'s unit types. C# is okay and all, but F# is, IMO, the best FP-language-on-a-corporate-backed-VM ever, even if the integration with the underlying VM and interop can get a bit fiddly in places (Caveat, my opinion is about 7 years old).

Yeah, you heard me Scala.

>Having everything work this way makes it so much easier to review code for errors.

Had one making me pull my hair put the other day in C#. C# datetimed are measured in increments of 100 nanoseconds elapsed since January 1st 1 AD or something like that. Was trying to convert Unix time in milliseconds to a C# datetime and didn't realize they were using different units. My fault for not reading the docs but having it in the name would have saved me a lot of trouble.

The wonder elm-units is such a pleasure to work with and does just that.

https://package.elm-lang.org/packages/ianmackenzie/elm-units...

Even if you don’t work in Elm take a moment to look at it.

Nitpicks:

Why would your type system have encoded unit for kilo-pascal, but not hecto-pascal, mega-pascal, micro-pascal etc?

If you only encode base units (e.g. seconds), then we should use exact-precision arithmetic instead of f32 or f64, which is sometimes an overkill.

If encoding all the modulos (kilo/milli/mega etc) I feel like there are some units may have name clashes (e.g. "Gy" -- is it giga-years, or gray)?

Should we encode only SI units, or pounds/ounces/pints as well?

In my software project, all measurements exist as engineering units since they all come from various systems (ADCs or DSP boxes). We pass the values around to other pieces of software but are displayed as both the original values and converted units. We have a config file that contains both units and conversion polynomials, ranging from linear to cubic polynomials. Some of the DSP-derived values are at best an approximation so these have special flags that basically mean "for reference only". Having the unit is helpful for these but are effectively meaningless since the numbers are not precise enough, it would be like trying to determine lumens of a desk lamp from a photo taken outside of a building with the shades drawn.

I love when types are used to narrow down primitive values. A users id and a post id are both numbers but it never makes sense to take a user id and pass it to a function expecting a post id. The code will technically function but it’s not something that’s ever correct.

Having units as part of your types improves legibility for whoever's writing code too, not just reviewing. You won't make (as many) silly mistakes like adding a value in meters to another in seconds.

If your use of a value in units lives for so long as for it to not be clear in what unit it is in or should be in (eg. spans more than 20 lines of code), I think you've got a bigger problem with code encapsulation.

I think the practical problem stems from widespread APIs which are not communicating their units, and that's what we should be fixing instead: if APIs are clearer (and also self-documenting more), the risks you talk of rarely exist other than in badly structured code.

Basically, instead of having `sleep(wait_in_seconds)` one should have `sleep_for_seconds(wait_time)` or even `sleep(duration_in_seconds=wait_time)` if your language allows that.

But certainly use of proper semantic types would be a net win, but they usually lose out in the convenience of typing them out (and sometimes constructing them if they don't already exist in your language).

The Python package astropy extends numpy arrays to include units.[0]

It can convert between equivalent units (e.g., centimeters and kilometers), and will complain if you try to add quantities that aren't commensurate (e.g., grams and seconds).

The nice thing about this is that you can write functions that expect unit-ful quantities, and all the conversions will be done automatically for you. And if someone passes an incorrect unit, the system will automatically spit out an error.

0. https://docs.astropy.org/en/stable/units/index.html

I think you would enjoy programming in Ada.

Have you come across a system or language that handles units and their combinations / conversions well? I have a project I want to undertake but I feel like every time I start to deal with units in the way I feel is "proper" I end up starting to write a unit of measure library and give up.

> physical quantities should [...] be encoded in the type system.

But types are not just useful to specify the content of a variable, they are also useful to specify the required precision.

So, if there is a type for seconds in the type system, should it be a 32 bits int or a 64 bits float? Only the user can say.

And let's not forget money. Martin Fowler has been (correctly) banging this drum for years: https://martinfowler.com/eaaCatalog/money.html

You don't need a type system to do this. Generic operators/functions and composite structures are sufficient and more flexible. Some languages let you encode this in type systems as well, but that's an orthogonal feature.

Add to this any type of conversion or relations between units.

PIXELS_PER_INCH or BITS_PER_LITER rather than SCREEN_SCALE_FACTOR and VOLUME_RESOLUTION, avoids all kinds of mistakes like inverting ratios etc.

For everyone using Python and willing to try this:

https://pint.readthedocs.io/en/stable/

I'm sorry, but this whole comment section is in some collective psychosis from 2010. You don't need to mangle variable names or create custom types (and then the insane machinery to have them all interact properly)

Have none of you ever refactored code..? Or all of your writing C?

Your library should just expose an interface/protocol signature. Program to interfaces. Anything that is passed in should just implement the protocol. The sleep function should not be aware or care about the input type AT ALL. All it requires is the input to implement an "as-milliseconds()" function that returns a millisecond value. You can then change any internal representation as your requirements change

You might find this interesting: https://github.com/SciNim/Unchained

There are usually libraries for doing this. For Python, there are several, for instance “Pint”.

> Option 2: use strong types

This is just about the best justification I have heard for type calculus.

I think Go has a reasonable approach:

  time.Sleep(1 * time.Second)

Like many things with Go, its approach seems reasonable and simple at first, but allows you to accidentally write code that looks right but is very, very wrong. For example, what do you think this code will do?

    delaySecs := 1 * time.Second
    time.Sleep(delaySecs * time.Second)

Now I insist on using the durationcheck lint to guard against this (https://github.com/charithe/durationcheck). It found a flaw in some exponential-backoff code I had refactored but couldn’t easily fully test that looked right but was wrong, and now I don’t think Go’s approach is reasonable anymore.

I’m not a Go developer, but I understand that from a type and mathematical theory perspective Go’s time.Duration is extraordinarily awful, because of Go’s simplistic type system.

int64 * Duration → Duration and Duration * int64 → Duration both make sense, but I gather this only works with constants. For other values, I believe Go only gives you Duration * Duration → Duration which is just wrong, wrong, wrong, requiring that one of the two “durations” actually be treated as though unitless, despite being declared as nanoseconds.

In the end, it’s probably still worth it, but it’s a case of Go trying to design in a certain way for ergonomics despite lacking the type system required to do it properly. I have found this to be a very common theme in Go. Also that it’s often still worth it, for they’ve generally chosen their compromises quite well. But I personally don’t like Go very much.

Go's time package is famously horrible. First they didn't expose any monotonic clocks only wall time. Then after some public outages, like time travelling backwards for Cloudflare they were forced to act. In the end they managed to fold monotonic clocks into into the original type to cling on to the "Go just works" mantra, but adding even more edge cases.

https://pkg.go.dev/time#hdr-Monotonic_Clocks

> RRDNS is written in Go and uses Go’s time.Now() function to get the time. Unfortunately, this function does not guarantee monotonicity. Go currently doesn’t offer a monotonic time source (see issue 12914 for discussion).

https://blog.cloudflare.com/how-and-why-the-leap-second-affe...

> time: use monotonic clock to measure elapsed time

https://github.com/golang/go/issues/12914

Rust has a similar-ish API for durations, Duration::from_milis(1000) or Duration::from_secs(1) in the type system, and the method can just take a Duration struct and transform it into whatever internal representation it wants.

There is a Duration::new() constructor that's more ambiguous, but it's your choice as a dev to be ambiguous in this instance, and code review should probably catch that.

Or Ruby on Rails:

  sleep(5.seconds)
  sleep(1.minute)
  sleep(2.hours)

etc etc

In Ruby that would be

    sleep 3.seconds

Hard to to be more concise than that

Or Dart

    Future.delayed(const Duration(seconds: 2)
    Future.delayed(const Duration(milliseconds: 2000)

That’s similar to Crystal. All numbers have built in methods to convert them to a Time::Span object. So I could have a function that takes a Time::Span instead of an Int, like:

    def sleep(num : Time::Span)
      # do something here
    end

I would call it like:

    sleep 300.seconds

I'm not sure why but I have a visceral, negative response to this. It might be the best solution, but it definitely /feels/ like the worst of all the worlds.

I hope late millenials and generation Z rediscover types soon.

Big fan of this.

And if you're working with an existing system that doesn't accomodate the suggested options, a well placed comment can go a long way. Provide the unit as well as WHY that value exists.

    # Session inactivity, in seconds
    time.sleep(300)

    # Prevent pileup of unprocessable requests, in seconds
    request_timeout = 10

Comments are misunderstood far too often as some sort of accompanying inner monologue. Instead, I see a lot of noise like

    # Sleeps before continuing
    time.sleep(…)

    # Time before request timeout
    timeout = …

One more tip: If you're ever designing an API like this, instead of:

time.sleep(300)

Put your units in the method name:

time.sleep_seconds(300)

Likewise, if you're making a .length() method where the units are at all ambiguous (like the length of a string), name your units. Bad: str.len(). Good: str.len_chars() / str.len_utf8_bytes(). (I'm looking at you, Rust!)

time.sleep_seconds is appealing, but this approach doesn't work when a function takes additional arguments. for example, if your function is

  poll_file_descriptors(read_descriptors, write_desciptors, timeout_in_seconds)

it would be awkward to change the name of the function just because on of the arguments happens to refer to time.

This is where Objective C brings subtle magic with mid-function name arguments. Sure it's crazy verbose but insanely readable: printFile(file: File)withDelayInSeconds(delaySeconds: int)andPrintColor(PrintColor: UIColor)

I would always make a local variable for things like this, to avoid magic numbers (especially if a function signature has several numeric arguments). Then you can explicitly put the units in the variable name, e.g. duration_s = 300 and pass that. It's fine if the signature tells you the units, but it doesn't help anyone reading the code if you have poll_file_descriptors(read_descriptors, write_desciptors, 300).

I'm sorry, but if a language forced me to write str.len_utf8_bytes() every time I wanted the length of a string, I'd just stop using that language.

Though it might encourage some to consider str.len_extended_grapheme_clusters()

Out of interest, which length did you want?

The solution to this is as old as salt:

  typedef int seconds;

and

  time.sleep(seconds duration);

That doesn't really seem better, because the fact that the unit is seconds is only obvious if you happen to be looking at the function signature in the header or somesuch. This is because C typedefs are type aliases, not newtypes. If seconds were instead a struct with a single int field, or something like that, then that would help a little. To really solve this problem, you need information hiding, which C doesn't have except through questionable hacks.

I once went in to clean up a project that was designed by a committee of people spread all over the world. The unit was large moving equipment that if something went wrong, people might die. The unit was composed of several different CPU modules communicating on a property bus. Each module's software was written by a different group in a different part of the world.

The operator's requested speed was input in Feet Per Minute. The output to a Variable Frequency Drive was in tenths of Hertz. The tachometer feedback was in RPM, and to top it off all the internal calculations were done in Radians-Per-Second.

The first thing I did to get the project back on track was to adopt a standardized variable naming convention that included the units. For example the Operator Request became operator_request_fpm_u16. You then knew immediately you were dealing with Feet Per Minutes, and that it was a 16 bit unsigned variable.

After the variable name cleanup many of the bugs became self documented, when you saw something like "operator_request_fpm_u16 / vfd_hz_s32" in the code, you knew there was a problem that needed to be fixed...

This is Hungarian notation. A combination of both flavors into one. https://en.wikipedia.org/wiki/Hungarian_notation.

My take is that Hungarian notation exists to work around a deficiency in tooling. I think this is clearer when encoding e.g. u16 into the identifier, since that information is redundant (the declaration or schema already encodes that it is u16).

Worth mentioning Frink.

> Frink is a practical calculating tool and programming language designed to make physical calculations simple, to help ensure that answers come out right, and to make a tool that's really useful in the real world. It tracks units of measure (feet, meters, kilograms, watts, etc.) through all calculations..

https://frinklang.org/

Frink's units definition file is a great read: https://futureboy.us/frinkdata/units.txt

I use Frink very regularly as a calculator. I've got a keybinding in emacs to bring it up in comint-mode, which works very well.

It's also a general-purpose programming language, at least in theory. I actually tried using it for that purpose once, with I think a few thousand lines of Frink code in total. It was not a pleasant experience. It's fine if you want to write a short script that's dimensionally aware, but for modelling of a complex physical system there are much better tools, such as Modelica.

A really great read. I found particularly interesting the long comment about the Hertz inconsistency, I had no idea the S.I. Hertz, when applied to circular motion, was not a full circle per second.

I typically stick to "SI" units.

Then, somebody asks me to code in the temperature of a system. And I have to think: "Is now really the time that I want to teach people the difference a kelvins and celsius?"

So my rule becomes, SI "except" temperature. Sigh...

We also strictly stick to SI however we usually say kilograms in var names to be clear.

Haven't come across temperature however we would probably stick with kelvin.

We use a strict set of units in databases and while processing, conversions are localized if necessary only at the view layer.

We also only use UTC for date/times.

We only use E164 format (without spaces etc) for phone numbers: e.g. +12345678901 for an example number in OH, US. see National format https://libphonenumber.appspot.com/phonenumberparser?number=...

We only use iso3166-1 country codes and iso3166-2 region codes and translate on view.

This, one million times this. Use SI units. Don't measure distance in hotdogs, time in fortnights and speed in hotdogs per fortnight! It is as stupid as it sounds.

If you do, be explicit about it either in parameter or function name. I'm not going to put you on my shitlist if you're naming your function `microsleep`, but if I have to go look into implementation to see that you count timeout on your database in microseconds (looking at you, couchbase, like you ever could return something from a larger dataset in microseconds, lol) or, even worse, cache expiry time in minutes (hello unknown developer), I am going to go on the internet and complain about you.

This is actually an issue with thermal imaging cameras. Typically you'll get calibrated readings back in Kelvin, not in Celsius. Usually it's well documented by the camera manufacturer, but if you're providing an API to users you need to make them aware what the units are and make a decision on what you're going to return. For example this crops up if the sensor only provides counts which you need to convert into a temperature.

From a hardware perspective it makes sense to use K because you can encode the image directly using unsigned numbers plus some gain to allow for fractional measurements.

But you're still including the units in your identifier names (or encoded in type system), right?

which is great when you're writing from scratch, but as soon as you have to start calling a library with functions based in non-SI units then you've got some ambiguity.

There should be a exception in every code standard that says SI units are OK where otherwise all lower case is enforced. Example to use mega (M) vs milli (m).

MKS or CGS?

I'm confused, because one delta degree Celsius is exactly the same as one delta degree Kelvin. And you can convert with an offset.

in the genre of naming things, some related things to explore:

- avoiding naming things if you can help it

- using tooling to autogenerate names

- avoiding too short, likely overloaded names like `id`, `name`, and `url`

- don't choose lazy pluralization - eg instead of `names/name`, use `nameList/nameItem`

- encoding types to make Wrong Code Look Wrong, a famous Spolsky opinion (lite hungarian notation)

- coming up with grammars for naming, eg React had an exercise to name its lifecycles combinations of THING-VERB-ACTION, like `componentDidMount`, before open sourcing, which helped learnability

pulled from my collection of Naming Opinions here: https://www.swyx.io/how-to-name-things

>- don't choose lazy pluralization - eg instead of `names/name`, use `nameList/nameItem`

Isn't this just extra noise? If the type of the variable is an Array wouldn't `nameArray` be superfluous? Worse still is if the type changes but the name stays the same.

I get the advice is probably Javascript specific, but even in a Typescript world it doesn't make much sense to me to do this kind of type-in-name encoding.

Even in typed languages `names` and `name` are too similar to slow code reading down.

> avoiding too short, likely overloaded names like `id`, `name`, and `url`

In a small enough context, no way :)

> don't choose lazy pluralization - eg instead of `names/name`, use `nameList/nameItem`

This just seems redundant and is a personal annoyance. Is plural meaning list or sequence not widely understood enough?

Next step, please don't call your variables ..._percent but interpret 0.5 as meaning 50% of the reference value.

I 100% agree.

That said, "percent" is a common and precise word, and I haven't come up with anything quite as good for variables in range [0,1]. I generally use "ratio," but I don't love the word. Is there anything better?

Bad naming is a universe of programming flaws, much of which boils down to not thinking about how a different person might read your code the first time.

Unfortunately "Theory of Mind" is weak in people on the spectrum.

How do you mean?

Or join the ranks of your peers who have seen the light and use types.

Documentation should always be secondary to an obvious, descriptive interface. We've evolved beyond register positions and phonebook-style paper documentation. Use the tools available to you.

That would be the second paragraph in the article

The article addresses this somewhat using Python's type hints. If I give you his signature, can you intuitively tell me what unit is being taken in by the function?

    void addPadding(int height) {

    }

Types are useful, and even as a Python programmer I gravitate towards type hints for all new code, but any application where a programmatic type maps to a real-world type with common conversions (like, say, pixels, em, en, millimetres, centimetres, or inches in the above example) tends to be a victim of the same issue, where the type system isn't expressive enough to clearly describe the real-world type being assumed by the function.

the article mentions strong types

I can understand the reasoning, in this specific case. But having every function designating their unit is a new hungarian notation. Imagine working with:

setSpeedInKilometersPerSecond vs. setSpeed

I'd rather have it baked into the language ala CSS ("100ms").

First, I'd say that you probably want to invest in your IDE or editor.

But more important: there's middleground. What about setSpeedMmps() if setSpeedInMillimeterPerSecond is too noisy.

My ROT is that the unit or type designation schould not overshout the most important info. Which, in case of setSpeedInMillimeterPerSecond is arguably, indeed the case. But the solution is almost never binary, but a more succint version. Everyone understands km, mm, sec, hr (though the win with such is silly) px and so on.

Do they charge you by written bytes? I really don't see the problem with larger function names...

You are missing one crucial element here: `setSpeed(meterPerSecond: float)`

Are you coding without any form of auto completion?

For C++ you can use boost units. It is basically built up of template magic which only compiles when your units are correct. The disadvantage: when it doesn't, it explodes in a huge template error. But when it does, you can be pretty certain (depending on the actual calculation) that your code is correct. It is also fully verified at compile time, so there is no runtime overhead.

https://www.boost.org/doc/libs/1_78_0/doc/html/boost_units.h...

I prefer using timedelta (or TimeSpan for the .NET crowd) but I’ve run into a somewhat funny resulting problem: often these time values are read in from a config file, so now people need to know/remember the serialized time span format. Like what is “00:50”? Is it fifty minutes? Seconds?

Sure, we got used to the format. I have a gist that among other things lists all of the cases, including the harder ones such as "10ms", or "3 days".

FWIW, in "TimeSpan for the .NET crowd", you would write "00:00:50" for (zero hours, zero minutes and) fifty seconds. Hours, minutes and seconds cases are easy now that we know the format.

Yes, you can omit some of the zeros, but your comment above makes the case that for clarity, you should not.

That's why you use a constructor with the unity names, not the conversion from a unityless string.

You don't have to use the default serialization format. You can have `timeout_seconds = «int»` or `timeout = «int»s` in your config file, store it internally as timedelta, and convert when you read the file.

Along these lines: if you are designing an API for pricing data or fintech and think “let’s send things in integer cents of the currency so there aren’t any rounding errors” - setting aside that there are many situations where this is not appropriate, if you do still want to do this, for the love of Pete please name your variables and attributes with `_cents` in the names. No exceptions. It is the biggest unit-related footgun imaginable, and since it’s not a “unit” technically, it’s easy to overlook.

Assuming all currencies have 2 decimal units and subunits have 1:100 ratio is another major footgun: https://en.m.wikipedia.org/wiki/ISO_4217

As we all know, naming things is so difficult.

Most currencies do not have "Cent" as a base unit. And there are currencies without a smaller base unit, most notably japanese Yen.

The problem is, that there exists no established currency neutral name to distinguish between the two possible units that coincide in such cases as Yen.

I was thinking about the following:

  class AmountOfMoney
    property int FinerAmount
    property decimal CoarserAmount

In the case of Yen (FinerAmount == CoarserAmount) is always true.

Any suggestions for better wordings?

In Python you can force the use of a parameter’s name with *

  def my_sleep(*, seconds: int):
     pass

  my_sleep(seconds=3)

This will force those who use your function to use the parameter name. A sort of documentation I suppose.

That's in the article...?

Sometimes the verbosity annoys me a little while writing it, but I do think Rust made the right decision making you write code like the following to use the standard sleep function.

  std::thread::sleep(Duration::from_millis(300));

In Ada you can do something similar:

    delay 0.3;

Or with package Ada.Real_Time:

    delay To_Duration (Milliseconds (300));

Or use `delay until`:

    delay until Clock + Milliseconds (300);

`delay until` is useful in loops because `delay` sleeps at least the given duration, so you get drift. (You call Clock only once and store it in a variable before the loop and then update it adding the time span each iteration)

In fact std::thread::sleep doesn't exist. There's sleep_for and sleep_until. Time deltas and time points are incompatible at the type level, so you have to do:

   std::this_thread::sleep_until(std::chrono::system_clock::now() + 300ms)

That's true for all functions that take timeouts (At least since C++11).

edit: s/thread/this_thread/

If you're passing around parameters, use a Duration class. Most languages have one:

* https://docs.oracle.com/javase/8/docs/api/java/time/Duration... * https://docs.microsoft.com/en-us/dotnet/api/system.timespan?... * https://en.cppreference.com/w/cpp/chrono/duration

If you're putting something in a config file, as the blog says - always put the unit in the key name.

If you're using Javascript or Typescript, there is an Eslint rule called "no-magic-numbers" which enforces a rule where numbers are required to be assigned to a variable: https://eslint.org/docs/rules/no-magic-numbers

You can set ones to ignore, a minimum value for the rule to apply, or require the variable to be a const.

I'm a fan of the middle ground here where you limit magic numbers to known constants and arithmetic. This means some constants don't have magic numbers, but also some inline uses don't necessarily have constants.

For instance 7, 24, 60, 1000 allowed in defining units of time, and any other intervals are defined as 5 minutes = 5 x 60 x 1000.

Still, I've had plenty of experiences with 'is this unit in seconds or milliseconds'. As I recall, Gilad Bracha at one point looked at attaching units to numbers but I think he got wrapped around the axle on automatic conversions - if you divide meters by seconds, this is a meters/second unit. But do you convert to newtons or joules automatically too?

This is more about units.

int length = 5

Is quite different than:

int lenght_in_meters = 5

I've heard of some Ada coding standards that require this in all variable names. It must have made the code awfully clumsy, but as the examples in OP show, it can be made nice. So the general advice is good. I'm slightly disappointed that the Haskell library didn't use a newtype, e.g. threadDelay (Microseconds 300).

Haskell has a couple libraries that would be great here; either the excellent time library, or the very powerful dimensional library with full statically typed SI units. Of course for something as core as threadDelay, a newtype is more appropriate as you say.

"Native" Ada way would be to declare units in types and require explicit casts (also, you can prevent casting to unsupported types, so no retrieving Int64 from hypothetical Duration_Nanoseconds

Most people are talking about time here, but the one I've seen that has caused the most issues in my experience is deg/rad. UI are pretty much always going to be in degrees, and trigonometric functions in radians, but if you forget to convert it's not always going to be obvious.

Yes, don't use Magic Numbers, but use named constants instead.

http://catb.org/jargon/html/M/magic-number.html

https://en.wikipedia.org/wiki/Magic_number_(programming)

    delay_ms = 300;
    [...]
    Thread.sleep(delay_ms);

Works in any programming language.

Fails in any programming language, too.

    delay_seconds = 300;
    [...]
    Thread.sleep(delay_seconds);

This kind of bug can easily surface if you need the constant for calls taking different units and can be hard to spot.

Yes; still parent solution is better than nothing if you have to deal with an existing API. At least if you make a mistake there is a chance someone else might spot it instead of wondering what the original intent was.

C++ has, in recent years, improved support for this. The best state of affairs is with time units:

    using namespace std::chrono_literals;
    auto lesson = 45min;
    auto day = 24h;
    std::cout << "one lesson is " << lesson.count() << " minutes\n"
              << "one day is " << day.count() << " hours\n";

and you can compare durations specified with different units etc. There mpusz/units library, which may go into the standard at some point, lets you do this:

    using namespace units::isq::si::references;

    // simple numeric operations
    static_assert(10 * km / 2 == 5 * km);

    // unit conversions
    static_assert(1 * h == 3600 * s);
    static_assert(1 * km + 1 * m == 1001 * m);

and also write conceptified functions which "do the right thing", e.g.:

    constexpr Speed auto avg_speed(Length auto d, Time auto t)
    {
        return d / t;
    }

this will normalize appropriately. But - the specific units used will need to be known at compile-time. Choosing units at run-time is a different kettle of fish.

I recently worked on some disk file formats (.vmdk, .vhd), and I always put the units in the name, because I'm always switching byte, sectors, blocks. Same for addresses, is it a LBA on the virtual disk, or an offset in the disk image file.

When I learned Objective-C I remember being flabbergasted at all the method and argument names that were exceedingly wordy. At some point I read a blog post[0] that said while this is out of the ordinary when it comes to most code having long, descriptive names helps when reading code.

Some people complain that it involves too much typing or takes up too much space. In reality, we spend much more time reading code than we do writing it, so names that provide context, direction, and fore-shadowing are really useful.

I still tend to write method names and important variable names like that to this day in pretty much any language I use. IMHO, its a great hack.

An extreme example is in the NSBitmapImageRep class [1]

[0]: https://www.cocoawithlove.com/2009/06/method-names-in-object...

[1]: https://developer.apple.com/documentation/appkit/nsbitmapima...

Autocomplete handles the "too much typing" case.

> Don’t design your config file like this:

> request_timeout = 10

> Accept one of these instead:

> request_timeout = 10s

> request_timeout_seconds = 10

What does ”s” imply? Can I write “10m” for 10 minutes, or is that 10 months? Non-standardized syntax is dangerous.

For config files, I use RFC 3339 duration syntax; i.e. “PT5M” for five minutes. It was the most standardized syntax for semi-human readable time periods which I could find.

`m` is not a legal value, should be either `min` or `mo` for minutes or months respectively.

`s` is actually one of the SI base units: https://en.wikipedia.org/wiki/International_System_of_Units#...

edit: actually, month should never be used for the case described anyway... 28-31 days?

Had I seen PT5M I would have never guessed it meant five minutes, so you would need to refer to the RFC then.

Agree with the post.

On JSON, I always do { unit:XXXX, value:XXXX }, it is quite verbose but it does help a lot when you least expect it.

I also wrote a small utility that transforms between values like { unit:'m', value:5 } to { unit:'km', value:0.005 } so that makes it super easy for me to pipe stuff from one context to another when is needed.

Do you have a link to this utility?

Java has a good library that supports a variety of measurement units: javax.measure https://docs.google.com/document/d/12KhosAFriGCczBs6gwtJJDfg... http://unitsofmeasurement.github.io/unit-api/site/apidocs/ja...

The java.time API goes in the same direction, but is obviously limited to things around time.

I think units should be really expressed with the type system, because types give meaning _and_ safety. If used APIs require typed units you wouldn't even need a coding convention to put the unit in a variable name.

An often better solution is to have a type which is not an integer/string as input and have various ways to convert from/to integers in a unit showing way.

Types like e.g. Duration (for e.g. sleep), Instance (for calculating time passed based on monotonic timestamps), Distance etc.

Through at the same time in static typed languages being generic over the unit is often unnecessarily and hinders productivity (e.g. Duration<TimeUnit> with types Duration<Seconds>, Duration<Hours>) similar having unit types (e.g. passing instances of Seconds, Hours to sleep) is also often not necessary and more harmful then good. (Exceptions exists, where you e.g. need to have where high precision and range while at the same time need to keep storage constraints as small as possible while also juggling units, like some scientific or embedded applications).

Or use an IDE? Here[0] is a screenshot of the Java example in idea, not only does it show an inlayed parameter name hint, but simply mousing over the method will show you the documentation.

[0]: https://i.imgur.com/8UcEO5N.png

This doesn't work looking at a PR.

It also doesn't make a unit error stick out, as you have to take the time to specifically hover to check. What I mean by this is consider you've opened a mature code base and are browsing around, and scroll past:

    timeout = 60000;

I'd assume this is milliseconds, and whether I check would depend on what I'm doing and probably also my mood.

Whereas if I see:

    timeoutSeconds = 60000;

It'll draw my attention and no matter what I'm doing I'll either open a bug or just fix it.

Programs should be comprehensible as text, without machine assistance.

Preach! This is a big issue across all projects written in any programming languages.

Without this small info, you have to grep the docs or worse, grep the source code itself. There's nothing wrong with looking at the source code but you shouldn't have to if you just want to use the public interface.

Please do not, unless you are actually implementing unit conversion logic.

Pass around types encoding certain quantities. You do not want a Thread to "sleep for x units", but rather "sleep for this specific Duration", therefore pass around Durations and implement appropriate utilities `.toSeconds(Duration d)`, `.fromTime(Time t1, Time t2)`. The very moment your `.frobnicate(int time_in_seconds)` gets wrapped in `foobar(int duration)` all meaning is lost and you have no control over it.

Type systems are there to encode meaning (sometimes including possible values) behind a value - use it. And if you use highly dynamic prototyping language in production... Well, inability to encode and enforce meaning behind a value is part of the compromise.

From the article:

> Option 2: use strong types, An alternative to putting the unit in the name, is to use stronger types than integers or floats. For example, we might use a duration type

This is not exactly the same thing, but for the love of god, if you have a monitoring or logging product, make the date and time zone visible wherever time is displayed. I cannot tell you how many times I've been sent screenshots of graphs, showing some catastrophic scenario at, say, 08:43, with no idea of what time zone the graphs are using, or what day the graph is showing.

make everything UTC, people. It'll make your life way easier. Try it out.

Yeah, this is also happens in code. The solutions are the same, either use a type that is unambiguous (`timestamptz` in Postgres, `datetime` in Python with `.tzinfo is not None`, `DateTimeOffset` in .NET, `UTCTime` in Haskell etc.), or if you have to use naive datetimes, put the time zone in the name and call it `datetime_utc`.

If it was a Google product, it's implicitly Pacific Standard Time.

I prefer the use of Unix timestamps. Easier to filter with standard Unix tools, and if I really need formatted date+time in my output, I can always use awk.

This usually bites me when it see a function that takes a parameter named angle. I usually have to read the docs or inline comment to know if it's in radians or degrees. At worst case, I have to go to read the implementation to figure it out.

C++ gets this right for time durations, and has packages that do it for other units as well.

Perhaps you mean one of these?

https://en.cppreference.com/w/cpp/chrono/duration

https://abseil.io/docs/cpp/guides/time#time-durations

In a lot of software you can enter units into input fields. For example in Blender I can move an object in a direction by entering something like: `(1m+5inch)/2`. Or I can set the max render time to `20sec` or `2min`.

When the input box is a function the only unit you need to know is 'distance'. So I don't completely agree with the article. A sleep function does not need the unit in it's name but should accept a domain unit: duration. The function itself can convert it to something the function can handle.

`sleep(2s+5ms)` should just sleep 2 seconds and 5 milliseconds.

Good C++ library for that topic is [0]. You can even go further and combine with something like [1] which is super helpful for kalman filters and other stuff where you have heterogeneous units in one vector.

[0] https://github.com/mpusz/units

[1] "Daniel Withopf - Physical Units for Matrices. How hard can it be? - Meeting C++ 2021" https://m.youtube.com/watch?v=4LmMwhM8ODI

but how can we keep the code readable even for people who haven’t encountered time.sleep before?

Contrarian opinion: You don't. You make people look up and internalise such information; that way they'll actually learn, as otherwise they'll forever stay within the realm of "beginner". Perhaps that's a goal for those who want to make programmers fungible (and I suspect a lot of the "readability" movement is merely an extension of that), but I don't think that's something we should encourage.

How is rote memorization of the arguments the stdlib of a language the difference between a beginner and an expert? I forget those kinds of things all the time, even for the language I use 99% of the time.

People have died because airplane mechanics thought they were working with one unit instead of another. Don't be a macho tough guy who thinks you'll never slip up.

Disagree.

What you say works at a small startup. Absolutely.

My reality and lots of other people at companies with larger code bases: you need to constantly look at code you have never seen before in one of many languages used at your company using one framework or another that is out of date by years or just came around the corner and you just heard the name of for the first time.

This is the reality of many an architect or team lead or principal engineer. Of course you will say: why make everything better for them, works fine for me who I only ever work in language X with framework Y? I agree that makes sense for the you of now. Why care?

Think about the future you. The principal engineer you. The architect you. Heck even just the 9 months from now you when you have moved on to the next framework. Never mind any other changes.

You’d prefer we made our code as hard to read as possible to increase job security?

Perhaps sleep in $YOURLANG is essential/trivial so there’s an argument that you should memorize it. OF course! It’s just one bit of info. But there are more APIs than sleep that take a number. Are they guaranteed to be consistent? No. What about `someVendorApi.setTTL(ttl: number)`? Is this also another thing to be looked up and internalized? What if there are hundreds of APIs that take numbers?

I would rather have my team spend time internalizing good design rather than the trivia of what units are associated with every numeric argument in every codebase.

Although there is some merit to learning by repetition and using memorization to keep core concepts top of mind, this is a very bad example of it since it’s literally just trivia. There is nothing at all fundamental about time.sleep being seconds. People memorize it because the have to and have used it enough times.

If time.sleep took a timedelta it becomes impossible to use incorrectly with a type checker since the caller specifies their own units. There is no merit to worshiping ambiguous design.

Sure, but how does the reader of the code know if the writer of the code did internalize this information or just made a mistake?

Swift is pretty good at this. e.g.:

  Task.sleep(nanoseconds: 3e11)

In swift I quite like DispatchTimeInterval's approach [1] (see Enumeration Cases). In most of my projects I end up adding a simple extension to TimeInterval to get the same behavior. Which makes reasoning about time very simple eg:

  Date().advanced(by: .hours(2) + .seconds(10))

I'm honestly not sure why TimeInterval doesn't include this representation by default.

1. https://developer.apple.com/documentation/dispatch/dispatcht...

or just have multi-dispatch, Julia:

  julia> using Dates

  julia> Millisecond(10)
  10 milliseconds

  julia> sleep(Microsecond(100))

  julia> sleep(Millisecond(10))

Maybe this is just me, but this suggestion seems worse than the problems

  def frobnicate(timeout: timedelta) -> None:
      ...

  timeout = timedelta(seconds=300)
  frobnicate(timeout)

Now instead of remembering that frobnicate takes an argument of seconds, one now needs to remember it takes a completely different type, the constructor for which now also needs to be memorized. When the main problem presented is one of memorization, this seems obviously worse?

The problem is one of readability, not memorization. A lot of readability amounts to taking what the initial author already knows and expressing it so that it's easy for everybody who comes after to know too.

Making implicit units explicit is a great example of that. Look at Martin Fowler's writings on Money types, for example. Or look at the $125 million failure of a space probe because people used implicit units: https://www.simscale.com/blog/2017/12/nasa-mars-climate-orbi...

> the constructor for which now also needs to be memorized

This seems less like a memorisation problem and more of an IDE one. If I'm presented with a type in my IDE, I can just look through its constructors and methods to find the one I require; no need for memorisation.

I suppose that it varies depending on the project/person, but I agree that using timedelta is less intuitive than just using seconds (as is done everywhere in Python).

Your editor will just tell you the type you need, no?

I remember as a kid, my Physics teacher used to penalize us for not writing the unit in the calculations. It seemed absurdly archaic at that time, but it makes so much sense now.

Thread.sleep (the java example) is ancient, but java is at least consistent and uses millis for everything. Almost all other timing functions in java have a 2-arg setup: `.foo(5, TimeUnit.HOURS)`. Where TimeUnit is an enum that has the usual options (HOURS, MILLIS, SECONDS, etc). It doesn't go beyond 'days' (once you get to months in particular, is that 28 days, 30 days, 31 days, 30.437 days (which is the actual average)....).

PHP offers sleep[1] and usleep[2] which sleep for a period in either seconds or microseconds respectively. I don't know why every other programming language ever hasn't adopted this habit. (There's also time_nanosleep[3] which definitely could be better defined, but it's PHP, sleeping for some amount of time between a nanosecond and a microsecond is pretty hilarious when you're running on an interpreter).

1. https://www.php.net/manual/en/function.sleep.php

2. https://www.php.net/manual/en/function.usleep.php

3. https://www.php.net/manual/en/function.time-nanosleep.php

The Unified Code for Units of Measure (UCUM) is a code system intended to include all units of measures being contemporarily used in international science, engineering, and business. The purpose is to facilitate unambiguous electronic communication of quantities together with their units. The focus is on electronic communication, as opposed to communication between humans. A typical application of The Unified Code for Units of Measure are electronic data interchange (EDI) protocols, but there is nothing that prevents it from being used in other types of machine communication.

http://unitsofmeasure.org

An example of use is in the FHIR (Fast Healthcare Interoperability Resources (hl7.org/fhir)) standard as a valueset.

https://www.hl7.org/fhir/valueset-ucum-units.html

[edit to remove dupe linke]

This is one of the reasons why I love F#, baked in support for units of measures. So instead of having to rename the function to include the unit I can just declare it to take the type `int<second>` and the compiler will complain if you try to pass an `int` or an `int<minute>` unless you declare an explicit conversion between the units.

Tangentially related:

Would love HN’s recommendations for blogs/writing on how to do better programming.

A lot of writing that I am exposed to is about the business of software, or engineering leadership, or architecture/tech stacks — which, to be clear, I really like reading, and find value in!

But I would love to read more thoughts on how to actually write good code on a regular basis.

Forever and always. :) If I see a numerical value that has units but doesn't in the name, I add it.

Also, I love F#'s units of measure.

PHP mess detector has a rule for this called "Magic Number Detector" (https://github.com/povils/phpmnd) which will cause an error when it encounters numbers that violate the parameters you set.

Similar topic, instead of var names, in typed languages you can use domain-specific types for primitives.

https://overcoddicted.com/domain-specific-types-for-primitiv...

I end up writing this function in most projects I work on. Python version:

    @lru_cache(maxsize=None)  # memoize
    def seconds(time_code):
        """number of seconds defined in DNS format: '2m30s' = 2 min 30 sec = 150s. h = hour, d = day, w = week"""
        result = 0
        number = ""
        for char in time_code:
            if char.isdigit():
                number += char
            else:
                secs = {"s": 1, "m": 60, "h": 3600, "d": 24 * 3600, "w": 7 * 24 * 3600}[char]
                result += int(number) * secs
                number = ""
        return result

Passing the time unit as a second parameter is used a lot in Java APIs and seems to work well

Java's Duration is also useful for time units

    void foo(Duration duration);

    var result = foo(Duration.ofHours(2));

You can also do simple calculations easily

    var bar = Duration.ofHours(2).plusMinutes(30);

...and so the tradition of loading up variable names with meta information that should really be in the type system is passed down from Hungarian notation to present day...

It's funny how the article talks about using the type system, but the title does not.

My strong recommendation at work is: _do not_ use configuration values such as "int dataCacheTimeMins" as these are prone to error, inflexible (cannot represent 2 mins 30 seconds) and not used consistently (will be mixed in with "int dataRequestTimeoutSeconds" and "int someOtherTimeMillis" and values named _without_ explicit units).

Instead always use "TimeSpan dataCacheTime" as this is more flexible: can hold values from sub-millisecond up to multiple days, and is easier to use with framework methods that will also expect this type.

In other words, use the appropriate type instead of putting the duration unit name in the var.

Eh, it seems the author never worked for a big organization and when it finally did, it has a pet peeve.

Lemme tell you, every single organization that respect itself, it will tell you, during code review, that you do not use magic numbers in code. It's a red flag, so his "Do this: frobnicate(timeout_seconds=300)" will actually fail the code review.

Here is what you would do instead. Declare a constant in some constants only unit, with explanation what it does and then use that constant, like this:

//constant unit

const TIMEOUT_SECONDS = 300;//bla bla why this is 300 seconds, usually from client requirement

//code unit

frobnicate(TIMEOUT_SECONDS);

But that still using a magic number, so obviously you should do something like this:

   const TIMEOUT_SECONDS = ONE * HUNDREDS;

The definition of ONE and HUNDREDS is left as an exercise.

Snark aside, the rule zero of all coding conventions is that they should not be applied if they do not make sense in a specific case.

In this case, the units are in the variable name. I think that was what the author was arguing for.

Julia seems to have some unit support (via package):

http://painterqubits.github.io/Unitful.jl/stable/

Is this not what comments are for?

frobnicate(300) // Duration in seconds to do X

Sure, change the variable names or whatever as well, but ... kinda seems we already have a way to make less obvious things obvious?

Problem with this is that you now need to ensure everyone adds that comment everywhere the function is used.

If it’s in the parameter name it’s impossible to use it without doing it correct, which is almost always preferable.

It helps. Even more so if documented with the function signature so documentation (in your editor or ide) can communicate it.

But one better than documenting comments is no documenting comments. Selfdocumenting code is certainly not always feasible. But in this case it's both possible and easy.

in the same vein, please name associative structures (hashes, maps, dictionaries, etc) as value-type-by-key-type (for example "username_by_id", rather than "username_lookup" or such. Conventions like these don't have an impact one-by-one, but rather when applied to a body of code as a whole. In this case when one has to do one lookup by the result of another the explicit "x-by-y" naming really helps reassure me the right values are being looked up!

In Elixir you can use an unused variable pattern matching:

    Process.sleep(_milliseconds = 300)

I started using it more and more because it makes the code more readable.

There's a good old article about this from Joel Spolsky

https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...

It also makes the distinction between "apps hungarian" (good, unit-types, eg: meters, seconds) and "system hungarian" (bad, storage-types: float, int)

Sadly I've never worked on a codebase that follows this.

A while back I made a units and dimensions library where I worked. Everything was built into the type system, with a required SI conversion for each unit of a certain dimension.

This did the job really well, but it was incomplete. Being able to create new types dynamically, when multiplying/dividing was something that was always missing. I guess now you could probably do this with macro programming, but back then I don’t think my language had it.

For an example of physical units done right check out the GEANT4 monte-carlo system. It pretty much "just works"

https://geant4.web.cern.ch/sites/default/files/geant4/collab...

Well, the only correct way to do it then is the way Python does it.

The SI unit is seconds. So unless you have some weird aversion to using decimals to represent smaller units, any kind of delay function should take input in seconds.

Not sure if this should be a cautionary tale about using units so much as using the correct units in the first place.

Apparently there's a Java function that lets you specify time units as secondary input. Use that to make in unambiguous.

Well, no. There are language's default unit is milliseconds.

The foundation of web, javascript is one of them. Send seconds in api to a frond-end without documenting is just confusing and hugely ambiguous.

And it makes more sense from the GUI's perspective. What did you mean paint next frame after 0.016s? Isn't it much easier to read when write it as 16ms?

When dealing with vectors, it is also important to establish your frame of reference. Sometimes, though by no means always, there is a well-established convention. When it is not, however, it can get verbose to encode into identifiers. It can also be tedious, as no-one needs to be reminded of it every time they read an expression. In these cases, documentation is the best choice.

When I put together Kal (a compile to JavaScript language, now defunct), I was particular about this and used the sleep syntax:

    pause for 3 seconds

With some other options for units. https://github.com/rzimmerman/kal#asynchronous-pause

This is a very valid argument. Go has this time.Second duration type that is used often and it helps a lot understand things. But things like Js/Pure Ruby have just raw numbers where you have to either check docs or just remember that sleep takes miliseconds or seconds etc.

It seems types are useful piece of information. Who would expect?

I have a similar nitpick with boolean arguments. How many times have you seen something like: DoSomething(true, false, false)? It's much more readable if you use enums (in a language that doesn't let you specify the argument name at the call site). E.G. DoSomething(ENABLE_REPORTING, USE_UTC, OUTPUT_VERBOSE).

I prefer to do this with types versus variable/parameter names where possible, but yep runtime names otherwise. It annoys some people but the thing is almost always either autosuggested or showing up in your editor as you type as docs, so… to quote Mitch Hedberg, “we apologize for the convenience”.

And, please, also attach units to numeric input fields in the UI so users know what they're entering.

I wrote about this a long time ago too: https://explog.in/notes/units.html. Units are critical, particularly when crossing language/engineer boundaries.

I thought this was in reference to the HNews post from WashingtonPost about the Eastern Antarctic being “70 degrees” warmer.

https://news.ycombinator.com/item?id=30733387

Does anyone else like to put data types in their variable names? Sometimes in finance I come across dollars and cents presented as an int and sometimes as decimal(18,2). So I don't confuse them I do something like payment_amt_d1802 or payment_amt_int.

Though you don't actually need to enforce keyword arguments, any good IDE will give you the (positional) arg names if you mouseover or w/e, so as long as the positional arg is named `timeout_ms` instead of `timeout` it should still be fine.

I think the problem is a bit more nuanced, but i don't have a perfect answer.

This is fine but relying on an IDE for code reviews really sucks. I'd much prefer to be able to do it on github. And it sucks for any language which infers types :( Scala is in particular awful for reviewing on github

IDE hints like this are useful when you're writing the code, but not so useful when you're reviewing it in online code review tools.

I wish code review tool could provide this hover functionality too.

I love the Duration class that Dart has: https://api.flutter.dev/flutter/dart-core/Duration-class.htm...

dimensioned[1] got me interested in Rust. I’m not far enough to recommend it, but the concept seems right.

[1] https://github.com/paholg/dimensioned

Unconventional take: just take the SI base unit any time. For time it's 1 second.

This is good scouting. In Java there is a naming convention. In<metric>, like TTLInMillis. In C# you often use TimeSpans, like TimeSpan.FromSeconds(123). However, I see this problem more and more often for some reason.

I ended up building a library for elixir a few years back for this kind of thing: https://github.com/meadsteve/unit_fun.

Probably already suggested but I'm a big fan of .Net attributes or other such decorators. A system level Units decorator which was respected in argument passing and maybe even automatically printed would be dope.

Ruby has a very neat syntax that can solve that. For instance, you'd just:

    sleep 5.seconds

    temperature = 0.17.kelvin

Not sure that last abuse actually works, but one may try. :-P

Ha. I've learned it decades ago. It is handled on a level of my spinal chord.

Same thing with explicit memory allocation. If for whatever weird reason I need to explicitly allocate RAM I first write deallocation.

This is something that I've done forever.

For example, when I create a static value to hold a constant, I usually do it like so:

    static private let _maximumButtonHeightInDisplayUnits = CGFloat(30)

Is there a standard for Durations, like we have for Time? (Like RFC3339)

ISO 8601 specifies durations [1]. For example, Java's Duration type [2] is based upon it.

Depending on your language, and how much type safety you want, you could use something Haskell's units library [3].

I believe F# also has units [4], possibly built in to the language? (I've never used F#.)

[1] https://en.wikipedia.org/wiki/ISO_8601#Durations

[2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base...

[3] https://hackage.haskell.org/package/units

[4] https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...

Ahh the cycle continues. We have lost touch with the lore of ages past, and only the old crones know of the Hungarian notation [1]. As we discover the ruins of old we glean their knowledge, and take up their practices because they were from a more civil time. What we don't recognize is that the creators of old didn't solve these problems and they were always in competition with themselves over which path is righteous. This ultimately led to their downfall, and the ruins you have discovered.

Take heed young adventurer: This balm will not solve all your ills. It will be your hard work, compassion, and perseverance that will bring the new golden age and sustain it.

TLDR: We've done this before, it solves some problems and causes other.

1: https://en.wikipedia.org/wiki/Hungarian_notation

*cough* Golang *cough*

    time.Sleep(42 * time.Millisecond)
    time.Sleep(42 * time.Second)
    time.Sleep(42 * time.Nanosecond)
    time.Sleep(42 * time.Hour)

The trouble with Go is that you can't multiple ints by Durations, leading to people doing `time.Sleep(time.Duration(x) * time.Second)` which is fine by itself, but then I see often people refactor and accidentally remove the second part.

The fact you can go from int to duration without specifying the unit does not give you the strong benefits. It's better than nothing though

    time.Sleep(time.Second * time.Second)

Ok, I'll bite. Why does time.sleep(secs) not accept keyword arguments, but

    def foo(x):
        print(x)

accept `foo(x='I accept keyword arguments!')`

time.sleep is implemented in C. For Python, adding keyword arguments to functions implemented in C takes a not-insignificant amount of additional boilerplate, so its often not done.

Julia supports zero-overhead units:

https://github.com/PainterQubits/Unitful.jl

https://web.mit.edu/jemorris/humor/500-miles

Somewhat relevant.

If you’re old you call this the Whole Value pattern.

http://fit.c2.com/wiki.cgi?WholeValue

Naming the method sleepMillis or sleepSeconds would help too.

In my opinion that's too specific as you'd need a dozen methods just to accomplish the common needs. Why not use a type as the argument that's explicit and meets even more use cases? Meaning instead of accepting an int just accept a `timedelta` in python or a `time.Duration` in go, or `2.seconds` (I don't recall the type) in rails?

Meanwhile in Java this is handled by the IDE. The IDE will insert the variable name since you are passing in just a number.

  Thread.sleep(millis: 300)

I don't think a language should require an IDE to be usable.

On a related, but not quite the same, it'd be quite cool to be able to express number literals as: 2K (for 2000), or 2K4 (for 2400), or 1Ki for 1024.

Discord API is guilty of one of these very examples, they send a retry-after header on 429 responses, but the thing is.. is it in Bananas? Apples? Elephants?

The retry-after header is documented as being in seconds (or a date). https://httpwg.org/specs/rfc7231.html#header.retry-after

Unfortunately it's part of http. One thing you can do is to send both the standard Retry-After header for tools that rely on it, and a nonstandard but unambiguous Retry-After-Seconds. That makes responses self-documenting. (One downside is that you now have two numbers, and if you introduce a bug that makes them different, it will be more confusing.)

Clicking on the link I though "I wonder it it starts with time.sleep"

It was a pretty safe guess, though, the number of bugs related to this is pretty epic.

C#:

    Thread.Sleep(TimeSpan.FromSeconds(3));

or with its int overloaded method:

    Thread.Sleep(millisecondsTimeout: 3000);

Or just document it. And the programmer should read documentation for the method. time.sleep() docs tells you exactly what units it uses.

Or, except if you need absolute precision, you wrap all those primitives in a function that uses SI. So seconds for your sleep wrapper.

F# has units of measure built into the language.

let time: float<s> = 0.1<s>

let length: float<m> = 10.0<m>

let speed: float<m/s> = length / time

My preferred way in Python is:

```

time.sleep(timedelta(minutes=5).total_seconds)

```

time_to_sleep = timedelta(minutes=5) time.sleep(time_to_sleep.total_seconds())

```

Unless I'm confident that I remember `time.sleep` wants a number of seconds, then I could miss an obvious error there.

For example...

    time.sleep(timedelta(minutes=5).total_milliseconds)

...looks just as plausible. So what does this solve?

One more related problem is coordinate systems for positions in any kind of robotics software or even 2d UI applications.

I disagree with this, you should infer the units from context. I don't want this hungarian notation in my codes

Somewhat unrelated, the typography and use of color on this article are sublime. No cookie popup either. What a joy.

Also, when using Go, use the time.Duration type in your API. It makes things unambiguous but adds no overhead.

imho it's bad practise to not use SI units [0] by default.

Why would you want to enter a percentage of a minute?

[0] https://en.wikipedia.org/wiki/International_System_of_Units

It would be much better to (also) put the units int the function name. Don't just have sleep() but sleepSeconds(). This prevents the person writing code from having to look up or guess what units the parameter has, as well as a person reading it later. This is more an API design issue than an API user issue, although both approaches can be used together.

But I this is not really necessary, if you use a IDE with integrated docs, where you see the parameters of a function on a mouseover.

Is there a programming language that supports units (and calculation with units) out of the box?

Units in values > units in names.

I regularly program in Go and Python.

When I hover over time.sleep(delay) in my Python IDE the detailed pop up shows me that this sleeps for delay seconds and that delay is an int.

When I hover over time.Sleep(wait) in my Go IDE, the popup shows me that time.Sleep takes a time.Duration.

Please get better tools and stay the heck away from both my languages and coding style guidelines.

In Golang, I've seen time.Sleep(2 * time.Second). That's pretty explicit, so, it seems someone carried the whole concept forward.

Agreed, always one of my peeves.

Haven’t had a mistype or a case of confusion with using Ada language to date.

just today I wasted some debugging cycles when my problem was using "sleep(500)" vs "usleep(500 * 1000)" (500 seconds vs 500 ms).

"why isn't my code doing anything?!"

> Option 2: use strong types

This should've been Option One

> And don’t design your CLI accounting app like this: > show-transactions --minimum-amount 32

I'd argue that it's fine if the accounting app is never going to handle multiple currencies.

Always missed Pascal’s typed scalar ranges.

what about having measure class instead. Ex:

Length object = Length.Parse(string);

Temperature object = Temperature.Parse(string);

this would but much simpler!

Rust got it correct imo.

300 * TIME_IN_SECONDS

In JS/TS I’d do:

await sleep(5 * MINUTES)

Where MINUTE and MINUTES is a constant for 60 * SECOND.

three_seconds=3000

...

time.sleep(three_seconds)

Ridiculous. You're supposed to know what you're doing. He should stop coding instead and do something that fits his skills.

When it's already too hard knowing the units of the function you're supposed to know, then why does he think he's supposed to code in the first place?

Bat-shit ridiculous. Of course people with low skills will be all over this, happily embracing it, but it's still absolutely ridiculous.

If you can't even remember this, then you should not be programming in the first place!

Wouldn't it help other to learn though if it's clearer? As you have to label variables, why not include units? How does that hinder you?

Do you label your variables a, b, c,...?

Reply on news.ycombinator.com