• (nodebb)

    In ES2015, parameter destructuring can be used to simulate named parameters.

  • RussellWakely (google)

    This pattern is a real bugbear of mine, implemented as it is by people I work with, except on methods with 10 or 15 parameters, because the method is a "convenient" way to create something provided by an opensource library: better to initialize something in one line, rather than many, right ?

    So instead of

    // "Thing" is a concept from the external library
    let thing = new Thing({
       paramWithReadableName1: 10, // integer value makes sense relative to "readable name"
       paramWithReadableName2 : 151, // we can imediately see which (of many possible) config settings are configured
       // we can just leave out parameters we don't need
    })
    

    we end up with

    let thing = OurLibWrapper.createThing(10, null, null, null, 151, null, null, true) // many more nulls possible if you want to use a later parameter

  • (nodebb)

    Every businessman knows that the middle man is the scourge of this world.

  • (nodebb)

    If your editor shows function signatures as you type, using named parameters means you know what you need to pass in. You don't have to look up the documentation and figure out what to put in the argument object every time you call the function.

    Of course, it makes those calls 10x harder to read, but they're easier to write, at least if you usually use all the arguments.

  • DrPepper (unregistered)

    There are eslint rules that can prevent that -- if there are more than 3 arguments to a method, it complains. This forces the method writer to change the arguments to be an object. Typescript can further enforce rules about what properties are allowed within that object.

    The WTF here is that this project is not using eslint.

  • (nodebb)

    I don't see it as too much of a WTF. Putting a wrapper like this allows you to easily instrument the call with timers of logging. Especially if you're using a flakey server.

  • Jeremy (unregistered) in reply to Auction_God

    It may not seem like an issue in a small codebase, but when the method gets adopted a bunch of times (or possibly worse copy/pasted) it may become very hard to maintain it. Features are easily added with new parameters, but deprecating and removing parameters becomes increasingly dangerous

  • Nick (unregistered)

    Two arguments in favour of this pattern:

    • IDE support for showing available parameters for the call
    • Decoupling from the third-party library in question

    In a language that supports named and optional arguments, I’d be fully in favour of this pattern.

    Even in vanilla Java, which doesn’t (yet) support named arguments, my IDE will add “hints” that show the names of each argument, so properly formatted code is still quite easily readable.

  • guest (unregistered) in reply to Nick

    Why the hell would you want to decouple from jQuery? You're literally using it as a wrapper library instead of calling fetch() yourself. If you write your own "decoupling" because you don't like the wrapper jQuery gives you, you might as well drop jQuery.

  • Airdrik (unregistered)

    People like that in-editor parameter hints feature as if it's the only needed solution to the problem. However that only works while everything is nicely lined up. Change the parameters on the method (i.e. add or remove a parameter in the middle) and now the hints are either misaligned or stop showing up entirely, leaving you to manually compare the function signature and count parameters. Just because the editor will show the parameter hints for you is hardly an argument in favor of N-parameter function pattern.

    Decoupling from a 3rd party library also isn't an argument in favor of an N-parameter function, but merely in favor of a wrapper function which could just as easily employ another parameter bag object and handle mapping from the library-agnostic parameter bag to the library-specific parameter bag (or function parameters if it doesn't employ a parameter bag).

Leave a comment on “Wear a Wrap”

Log In or post as a guest

Replying to comment #:

« Return to Article