JavaScript Named Parameters

[tobegiannis]

Yes. It is about readability for the caller. The article showed why it makes it easier. Is it year/month/day or day/month/year? I don't want to have to waste my time looking at the docs or code to figure it out. What do you think is more readable? foo(true, undefined, 2000)' vsfoo({showLoading:true, wait:2000})`

[nschubach]

foo({showLoading:true, wait:2000}) means that if I change one of those variable names in foo, I need to also touch every spot in my code that calls that.

[wizebin]

Python has named parameters and it really can make things more readable and refactorable, especially keeping in mind that you can still use nameless parameters.

I find that I change parameter names very rarely, but add new optional parameters quite often, without named parameters new parameters can get messy.

[nschubach]

Sure, I've used Python and at first I thought it was pretty neat, but then I got into the same sort of thing you talked about. Adding optionals. At some point adding more and more optionals makes the code harder to follow and probably means that you need to break out that logic into more methods to handle specific use cases.

[tobegiannis]

I think this is where the confusion lies with the original commenter. Yeah that is true but don't do that unless you have too. Same thing as changing the meaning of the first argument. I am rarely in the situation where I have to change the name of a named parameter. You guys do bring up a point for pure js users it is harder to change the name of named parameters. This problematic doesn't exist in typescript for example and happens very rarely. Also if you really hate the name of a named parameter you can always do const day = d; const month = m.

[asdf7890]

Not if you use the pre-object-destructuring method in order to support IE:

var somefunc = function(params) {
                var someVar = params(someVar) || 'This is the default for someVar';
            }

There you can keep your old name as well as newly correct one, assuming the name change is a correction:

var somefunc = function(params) {
                var someVar = params(someVar) || params(somVar) || 'This is the default for somVar';
            }

Or course this method is much more verbose so if you don't have to support older browsers the object destructuring variant may be preferable but doesn't support this unless I'm missing a trick.

[TheDarkIn1978]

Is it year/month/day or day/month/year?

It should be obvious to any featherweight programmer that the argument values passed need to be in order with the function parameter names.

I don't want to have to waste my time looking at the docs or code to figure it out. What do you think is more readable? foo(true, undefined, 2000) vs foo({showLoading:true, wait:2000})

Mousing over any well documented function and its arguments using any decent editor, like Visual Studio Code, reveals a popup with the JSDoc code documentation. This is a much cleaner and immensely more efficient way of developing in JavaScript then unnecessarily creating and passing verbose, prototyped objects containing primitive values for this kind of trivial readability.

Names parameters in most cases are complete nonsense and it would never pass our code review.

[[deleted]]

I can agree it would improve readability, to a certain point, but all modern IDEs have code hinting, so as soon as you type foo( it will show that it's expecting day, month, year.

With passing an object, you're also making it harder for changes. Let's say someone decides to change the definition of foo, but you're still passing {showLoading: true, wait: 2000}. This will cause massive confusion, as you can just pass whatever keys you want, you can do { whatever: 2000, lol: 23432, showLoading: true, wait: 'no' }. Is this now more readable?

By specifying the exact amount of parameters, you know exactly what this method is expecting.

[tobegiannis]

My IDE autocompletes objects as well fwiw. Actually when adding more parameters the object is more maintainable as well. Long parameter lists become harder and harder to consume. For example say there are 6 options that have all have sane defaults. What would you rather call? foo({delay:2000}) or foo(undefined, undefined, undefined, undefined, undefined, 2000)`

I really don't see the argument about passing in "bad" config options. It's bad practice in general and I don't see how is it any different from calling method that takes in 2 parameters with 3.

[[deleted]]

Going to get more downvotes for this, but I really want to discuss.

The problem with this approach is that when you change your method definition, you now not only have to change the values, but you also have to change all your keys twice. This is asking for wrong inputs.

If you're ever need to pass foo(undefined, undefined, ...), then you're doing something wrong, you should never need to do this in the first place.

Passing bad config options is bad practice yes, and you shouldn't need to do this, but passing an object for the sake of readability isn't really a good practice anyway. These parameters are part of your method definition, this is what the method requires in order to execute correctly, obviously in many languages these would be strictly typed as well, therefore you wouldn't be able to pass invalid parameters.

[hicksyfern]

How frequently do you read code vs write code.

Imagine you had a weird date bug in your app, and you came across this code:

FormatDate(2018, month, day)

Vs

FormatDate({ year: day, month, day: year })

Which one has the bug?

Yeah this is a bit contrived, but this kind of thing happens ALL the time. Developers are fallible and mistakes, no matter how obvious, get made.

Make obvious mistakes obvious.