4 ms·

or just use static typing and modern IDE

• eevilspock 5y ago
  Yes. Why pay runtime cost when there exists a dev and compile time solution? An good IDE like WebStorm will show the parameter variable names, even inline w/out needing to hover, providing the exact same info as RORO. On top of that use JSDoc to provide type info and documentation that shows as a tooltip. Or go whole hog and use Typescript.
  • presentation 5y ago
    When you have multiple parameters that are the same type, though, that isn’t foolproof. Maybe don’t do it everywhere, but do do it when misuse is likely (function foo(a: string, b: string, c: string): [string, string, string])
    • eevilspock 5y ago
      How is the RORO version better? function foo({a: string, b: string, c: string}) Give the params proper names, and the IDE will reveal them (inline even!) without RORO or its costs. Sure, for a return value like that, use an object with proper names. But that’s been a best practice without “RORO”.
      • presentation 5y ago
        Sorry, my example was bad - my point is that if you have it literally be named parameters in the RORO case there’s much lower chance to screw it up since the labels are apparent without needing to hover or trigger any kind of dialog. Chance you’ll mix them up just goes down, so while in theory it’s basically the same as the editor help case, in practice it’s way more foolproof. Would be cool though if VSCode and other editors had a way to make variable names somehow persistently visible on function invocations - that would be pretty interesting IMO!
        • eevilspock 5y ago
          > Would be cool though if VSCode and other editors had a way to make variable names somehow persistently visible on function invocations - that would be pretty interesting IMO! Looks like you missed what I wrote (twice). They do. Others have pointed out that VSCode supports it too. Search the comments for "inlay hints". You also are shown the parameter names and types when writing the function call.
          • presentation 5y ago
            Oh I’m dumb, thanks for clarifying!
• eyelidlessness 5y ago
  I’ve used TypeScript and VSCode for years and I still find this infuriating: const anything = (a: ActualTypeA, b: ActualTypeB, someOptionalFlagIveInspectedTenThousandTimesAndStillForget?: boolean) => IrrelevantReturnType What does the parameter mean? Is it in the doc block? (Almost never.) Does it default to false? (Now you’re reading the whole potential call stack.) Are additional behaviors associated with its absence or trueness that aren’t inferred at the call site? (Who knows but it’s a fair roll of the dice!)
  • ajxs 5y ago
    What's infuriating about this? If you give those variables good, descriptive names, and provide a default argument for the optional variable (which is just basic good programming practice), then what's the problem?
    • eyelidlessness 5y ago
      The problem is none of those things are visible where they matter. Sure your function signature might say what “true” means, and what parameter “true” is assigned to. Your IDE will probably even give you hints as you type. Those won’t show up in code review. They won’t show up in diffs at all if you rename the parameter and change its semantics.
  • heavyset_go 5y ago
    Why would you make a boolean parameter also an optional?
    • eyelidlessness 5y ago
      It’s really common in JS. Typically the default is false, but an unreasonably large minority including some really notable cases default true… which makes it that much worse.
    • Zababa 5y ago
      You write a function that does one thing, and then you realise it can be used for something else that's almost the same thing, so you add an optional boolean parameter.