3 ms·

A lot of these just seem to be arbitrary preferences. The author doesn't like capitalization in variable names and thinks twoWord is "objectively wrong" preferr

A lot of these just seem to be arbitrary preferences. The author doesn't like capitalization in variable names and thinks twoWord is "objectively wrong" preferring that languages accept two-word. Personally, I would prefer twoWord even in languages that accept two-word -- it is just too tempting to think it is subtracting "word" from "two" whether or not the language actually interprets it like that. There is no danger of ambiguity with twoWord.

JoshTriplett 10y ago
I've never had the issue with "moving the shift" that the author mentions, leading to "snake-Case". I don't think the way I type would allow that typo to happen; I certainly make typos regularly, but I don't think I ever have typos that move which character a shift applies to (Caps -> cAps). I do like languages like Lisp that let you use dashes in identifiers to avoid the need to shift, but at the same time, I also like identifiers_like_this just fine (much more so than identifiersLikeThis).
- kazinator 10y ago
  I often get errors like THis. This is the fault somewhere between the keyboard drivers in the OS's USB stack, or decoders of events in the UI. The problem is that I typed the H before releasing the shift key. However, the shift key is in fact released before H is released. The timing diagram is something like this: ___ T __| |_______ ____ H _____| |____ _____ Shift | |_______ The release of the Shift is a little late, so H gets it. The strict timing requirement to get this right completely non-conductive to fast typing. For instance, if I repeatedly drum my three fingers in a natural way on the Shift, Z,X (using my ring finger, middle, and index), and do it fast, here is what I get: ZXZXZXZXZXZXZXZXZXZXZXZXZXZXZX Key events should be tied to the release not to the attack, and the decision whether or not Shift applies should be made intelligently somehow based on the percent overlap. At the very least there should be some small (configurable?) holding period after the key down event before it is converted to an input character. Only after the holding period should it be decided whether the key is shifted, based on the current shift state at that time.
  - JoshTriplett 10y ago
    Interesting; perhaps that's an artifact of specific keyboards, and I've fortunately not used such a keyboard. (I have used keyboards with other unusual issues; for instance, I briefly tested a laptop whose keyboard had a wiring issue such that if you pressed three keys at the same time, the third would type a completely different key. I never realized until then that when typing certain common things, such as "mount", I chord across 3+ keys such that I press the 'n' before fully releasing the 'o'. On that keyboard, this would result in typing "mou~t".) That said, using a keyboard that had any lag between hitting a key and having it produce an event would rapidly break my brain and fingers; I expect a key to show up near-instantly after hitting it, nothing to do with when I release it.
    - kazinator 10y ago
      Funny though how we're used to UI buttons having release-triggers semantics, though! You can click OK on that "reformat your hard drive?" dialog---and as long as you don't release that mouse button, you can change your mind by moving the pointer out of the button, so it loses focus.

JoshTriplett 10y ago

I've never had the issue with "moving the shift" that the author mentions, leading to "snake-Case". I don't think the way I type would allow that typo to happen; I certainly make typos regularly, but I don't think I ever have typos that move which character a shift applies to (Caps -> cAps). I do like languages like Lisp that let you use dashes in identifiers to avoid the need to shift, but at the same time, I also like identifiers_like_this just fine (much more so than identifiersLikeThis).

kazinator 10y ago
I often get errors like THis. This is the fault somewhere between the keyboard drivers in the OS's USB stack, or decoders of events in the UI. The problem is that I typed the H before releasing the shift key. However, the shift key is in fact released before H is released. The timing diagram is something like this: ___ T __| |_______ ____ H _____| |____ _____ Shift | |_______ The release of the Shift is a little late, so H gets it. The strict timing requirement to get this right completely non-conductive to fast typing. For instance, if I repeatedly drum my three fingers in a natural way on the Shift, Z,X (using my ring finger, middle, and index), and do it fast, here is what I get: ZXZXZXZXZXZXZXZXZXZXZXZXZXZXZX Key events should be tied to the release not to the attack, and the decision whether or not Shift applies should be made intelligently somehow based on the percent overlap. At the very least there should be some small (configurable?) holding period after the key down event before it is converted to an input character. Only after the holding period should it be decided whether the key is shifted, based on the current shift state at that time.
- JoshTriplett 10y ago
  Interesting; perhaps that's an artifact of specific keyboards, and I've fortunately not used such a keyboard. (I have used keyboards with other unusual issues; for instance, I briefly tested a laptop whose keyboard had a wiring issue such that if you pressed three keys at the same time, the third would type a completely different key. I never realized until then that when typing certain common things, such as "mount", I chord across 3+ keys such that I press the 'n' before fully releasing the 'o'. On that keyboard, this would result in typing "mou~t".) That said, using a keyboard that had any lag between hitting a key and having it produce an event would rapidly break my brain and fingers; I expect a key to show up near-instantly after hitting it, nothing to do with when I release it.
  - kazinator 10y ago
    Funny though how we're used to UI buttons having release-triggers semantics, though! You can click OK on that "reformat your hard drive?" dialog---and as long as you don't release that mouse button, you can change your mind by moving the pointer out of the button, so it loses focus.