- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
In ES2015, parameter destructuring can be used to simulate named parameters.
Admin
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
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 parameterAdmin
Every businessman knows that the middle man is the scourge of this world.
Admin
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.
Admin
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.
Admin
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.
Admin
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
Admin
Two arguments in favour of this pattern:
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.
Admin
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.
Admin
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).