That's useful as an implementation detail, but even more important is the user experience of failing to debounce correctly. If I press a button (etc) twice within 100ms, that generally does not mean I want this to be seen as two presses. Rather, my finger slipped, maybe I have minor neurological problems, I'm drinking, the software itself glitched, whatever. For the user's sake, user interfaces should debounce themselves.
It's all rather striking to me, as the concept of debouncing was one of the first things I learned while reading microcontroller code as a child. (No, I'm not kidding--that was the only book on computers I could find growing up in BFE.)
That we still haven't generally solved this in 2020 is appalling.
(There are lots of variations. There was an article in Software: Practice and Experience in the 90s (?) lamenting the UI race in most X interfaces (and probably all other GUIs). Briefly, lots of interfaces can pop up a dialog or whatever while the user is pressing a button underneath. The dialog often gets the press, resulting in the software executing some action the user did not even see, much less intend.)
If a computer is going to disobey my instructions it should be extremely sure it's doing the right thing. 100ms is too long a threshold to make that assumption. 100ms repetition interval is only 10Hz, which is easily accomplished in short bursts by anybody with moderate skill in button mashing. I'd set it no higher than 50ms (20Hz), which is very difficult even in short bursts.
It depends on the context. If you're trying to fire your gun in a video game, sure, it should respect every button press (subject to hardware debouncing which is always required). If you're submitting an online payment, a delay of 10 seconds per order is still not enough. If you're posting in a forum, duplicates should be automatically pruned.
Trying to pin down the number of milliseconds without context is a great example of bikeshedding.
When I'm older or sicker, I'll use a thing that works for me when I'm older or sicker. Otherwise it's like turning on the screen reader for everyone because blind people can't operate computers otherwise.
That's great for people that are technically inclined. Spend some time with senior citizens and the disabled and you might develop a bit more compassion.
Overly long debounces are frustrating and 100ms is kinda questionable in that regard. And honestly if I wanted debouncing I'd get a mouse that did that.
It's all rather striking to me, as the concept of debouncing was one of the first things I learned while reading microcontroller code as a child. (No, I'm not kidding--that was the only book on computers I could find growing up in BFE.)
That we still haven't generally solved this in 2020 is appalling.
(There are lots of variations. There was an article in Software: Practice and Experience in the 90s (?) lamenting the UI race in most X interfaces (and probably all other GUIs). Briefly, lots of interfaces can pop up a dialog or whatever while the user is pressing a button underneath. The dialog often gets the press, resulting in the software executing some action the user did not even see, much less intend.)