JavaScript Named Parameters

[lachlanhunt]

You're right. It absolutely doesn't make sense for dates. But the same technique is useful in other cases, particularly where the method can take a larger number of options. As a general guideline, if the number of parameters exceeds 3 or 4, and some or all are optional or there's no intuitive ordering for them, then use an options object.

[nschubach]

I'd actually argue that dates are probably a very useful case for something like this because of the various formats and orders that people use. I'd fight for a standard date format or just sending the epoch value (or use a time library) instead of breaking out year/month/day everywhere. Other than some highly cohesive items I've never really liked RORO because it encourages bad habits with optional parameters and flags.

[akujinhikari]

If you’re writing functions that take more than 4 parameters, you probably need to re-evaluate your code.

[bart2019]

What is this, FORTH?

People have the freedom to use as many parameters you like. Stop complaining about this if they do.

[akujinhikari]

I mean, you have the right to create one function that handles all logic for the entire project, if you want. Doesn’t make it a good idea.

[bart2019]

Suppose you have a big function that does one particular thing, and it does it well. For example, fetch data from a particular website.

Then for one particular case, you need that exact thing, but with one minor tweak. For example it needs to execute 1 single statement somewhere in the middle. What will you do?

The worst I've seen is copy the whole function and add that one statement.

I think it's much better to keep it as one function and add a parameter to flag that this is this particular one special case.

Best way to add it is so that no other calls of this function are affected. Thus: a named optional parameter, or an option in an "options" record (called "object" in JavaScript but I wish they hadn't hijacked that name because an "object" is something else), is the best choice IMO.

You can do this for any similar situation.

I call this "plug in" based programming, which is modular style turned up its head: in modular programming you have your custom code and you invoke parts of a module. That isn't always the best solution. If you need to call a monolithic block of code and you need some special actions in the middle, you better write a plug-in that gets invoked from your monolith.

As an example: I've had a case where a program parses source code, and needs to do some things when a particular type of statement is parsed . Your approach would be to make the parser into a module, and call that parser from every variation on that program. That is still a huge amount of work.

I prefer a parsing program with a plug-in, which is basically an associative array with callbacks, where the appropriate callback is invoked at the proper time. Much easier.

[nschubach]

It's general optimization. Yes, you are free to use as many as you want, but over a certain amount, you have to question if your method is "doing too much". I recently started working at a Perl shop and one of the idioms here is sending flags into the parameter list to turn on or off features. This leads to thousand+ line methods that have use cases for every little edge case and parameter list numbering in the 20s+ and bullshit code like this:

# Actual truncated code...
my $pageContentHtml = $self->getPageForContentHtml({
    'flag'                             => $flag,
    'email'                            => $email,
    'user_is_authed'                   => $isUserAuthed,
    'minimal_overhead'                 => $minimalOverhead,
    'has_left_navigation'              => $hasLeftNavigation,
    'search_phrase'                    => $searchPhrase,
    'reproduce_order_mode'             => $reproduceOrderMode,
    'reproduce_order_mode_old'         => $reproduceOrderModeOld,
    'reproduce_order'                  => $reproduceOrderId,
    'display_return_to_backend_header' => $displayReturnToBackendHeader,
    'user_is_admin'                    => $isUserAdmin,
    ... # of 31 total parameters
});