First, sentences like "Not because it’s complicated. Just because I have no idea what I’m looking at." and "Tiny interruption. Still annoying every time." fatigue me, it's like you have an editor who, no matter what the content is, tries to spice up your writing with lots of little punchy exclamations, not everything needs such emphasis
Second, this may differ a bit from language to language, but maybe those booleans should not be a boolean: https://gleam.run/documentation/conventions-patterns-and-ant... for example isAdmin boolean could instead be a UserRole custom type, with variants Normal and Admin, which is easier to understand in the function call, and extendable with another Moderator (or whatever) variant
This is where something like "const bool isAdmin = true, sendWelcomeEmail = false" helps. Now your literal values aren't in the function call arguments anymore, but instead their meaning is, you just need to look elsewhere (probably the line right above it) to find their values.
There is something to be said for the bitmasks that are so common in C, createUser(user, ADMIN | SENDMAIL); has a lot more clarity than createUser(user, true, false, true);
I don't mind the object approach used here but its quite verbose in comparison even in Javascript. Having to name the variable and set whether its true or false is a lot more than needs to be done. Booleans in general have quite poor readibility and maintenance especially if a third possibility arrives.
Even though in OCaml's functional style it is actually like this:
createUser user ~isAdmin:true ~sendWelcomeEmail:false
Using the fact that a variable named exactly like a labeled argument is automatically assigned to it, we can make the call more concise (especially if reusing existing variables):
let isAdmin = true in
let sendWelcomeEmail = false in
createUser user ~isAdmin ~sendWelcomeEmail
Think the issue is not with named parameters per se, but with mixing domain logic = there are two different user creation flows, that should be doing two different things (or mostly different things), but are guarded with boolean flag.
As author points out: "So I’ll usually just make it explicit:
createAdminUser(user);
createRegularUser(user);
Now there’s not much left to interpret. To be fair, this isn’t always bad. Sometimes this is completely fine:
It's the one thing I miss from Swift when I'm using literally any other language. Interal and external parameter names. I would love for Rust to adopt:
fn foo(namedParam internalName: bool) { // use internalName here }
fn foo(unnamedParam: bool)
I've been using this pattern for the past couple years for the benefits the author mentions. In addition to that, it can help with overly complicated functions (which, ok, could probably be refactored) that have multiple optional arguments.
In the last couple of years I’ve started using named parameters a bunch more across languages. I consider objects like this close to the JS version of a named parameter. I probably would have thrown “name” in myself so it’s one arg for the whole func.
I feel like a goal with good code is localizing understanding even if it occasionally duplicates something like a parameter name.
named arguments are hacking object literals to provide additional readability. it's ok, but not for all code paths, they have a true overhead. problem is that these things start to become idee fixes in teams (all funcs should have named args!). ideally, this could be fixed in the language.
I wonder whether a person prompted this slop and is somehow unaware of the existence of LSPs, or if it's entirely automated and the planning subagent hallucinated this being an issue for humans.
First, sentences like "Not because it’s complicated. Just because I have no idea what I’m looking at." and "Tiny interruption. Still annoying every time." fatigue me, it's like you have an editor who, no matter what the content is, tries to spice up your writing with lots of little punchy exclamations, not everything needs such emphasis
Second, this may differ a bit from language to language, but maybe those booleans should not be a boolean: https://gleam.run/documentation/conventions-patterns-and-ant... for example isAdmin boolean could instead be a UserRole custom type, with variants Normal and Admin, which is easier to understand in the function call, and extendable with another Moderator (or whatever) variant
Exactly my thought. I know languages differ in support ... but enum is right there.
> toggleMenu(true); That’s clear enough. the meaning is obvious
so... it does toggle the menu? and toggleMenu(false) doesn't toggle it and keeps it as it is?
or is it toggle extended menu vs toggle basic menu?
This is where something like "const bool isAdmin = true, sendWelcomeEmail = false" helps. Now your literal values aren't in the function call arguments anymore, but instead their meaning is, you just need to look elsewhere (probably the line right above it) to find their values.
This one is a classic,
Avoid the Long Parameter List
https://testing.googleblog.com/2024/05/avoid-long-parameter-...
AI;dr: keyword arguments would be great in all languages, not just Smalltalk
Also, obviously bot/bought account.
There is something to be said for the bitmasks that are so common in C, createUser(user, ADMIN | SENDMAIL); has a lot more clarity than createUser(user, true, false, true);
I don't mind the object approach used here but its quite verbose in comparison even in Javascript. Having to name the variable and set whether its true or false is a lot more than needs to be done. Booleans in general have quite poor readibility and maintenance especially if a third possibility arrives.
This is commonly referred to as "the boolean trap". You'll find lots of articles about it.
OCaml has had labeled arguments for decades, so I assumed other languages would have added something similar by now. In C-style, it would be like:
Even though in OCaml's functional style it is actually like this: Using the fact that a variable named exactly like a labeled argument is automatically assigned to it, we can make the call more concise (especially if reusing existing variables):Think the issue is not with named parameters per se, but with mixing domain logic = there are two different user creation flows, that should be doing two different things (or mostly different things), but are guarded with boolean flag.
As author points out: "So I’ll usually just make it explicit:
createAdminUser(user);
createRegularUser(user);
Now there’s not much left to interpret. To be fair, this isn’t always bad. Sometimes this is completely fine:
toggleMenu(true);
That’s clear enough. This tends to work when:
- the meaning is obvious
- the function is small and local
- there’s only one flag "
It's the one thing I miss from Swift when I'm using literally any other language. Interal and external parameter names. I would love for Rust to adopt:
You can do this as a convention in javascript since 2015, but I haven't seen a library that does it:
C# has that
I've been using this pattern for the past couple years for the benefits the author mentions. In addition to that, it can help with overly complicated functions (which, ok, could probably be refactored) that have multiple optional arguments.
In the last couple of years I’ve started using named parameters a bunch more across languages. I consider objects like this close to the JS version of a named parameter. I probably would have thrown “name” in myself so it’s one arg for the whole func.
I feel like a goal with good code is localizing understanding even if it occasionally duplicates something like a parameter name.
Also known as ‘boolean blindness‘: e.g. https://cs-syd.eu/posts/2016-07-24-overcoming-boolean-blindn...
This has nothing to do with it.
You answered your own question. Call with
const isAdmin = true; . . . createUser(user, isAdmin, sendWelcomeEmail)
If you swap the order of isAdmin and sendWelcomeEmail you'll get no error from the compiler but now the names will be masking the actual behaviour.
named arguments are hacking object literals to provide additional readability. it's ok, but not for all code paths, they have a true overhead. problem is that these things start to become idee fixes in teams (all funcs should have named args!). ideally, this could be fixed in the language.
Agree that it would be nice to fix in the language. It seems like something that even a transpiler could take care of.
Ultimately I think I’d bias towards readability vs the marginal perf increase though.
I wonder whether a person prompted this slop and is somehow unaware of the existence of LSPs, or if it's entirely automated and the planning subagent hallucinated this being an issue for humans.
I was nodding along with the piece in the first half, then it repeated the same point five more times and I started to smell slop.
You can tell it was written by claude after just a few sentences, really.
Usable languages let you use named arguments foo(bar=zaz), and linters let you enforce their use for booleans.
https://kotlinlang.org/docs/functions.html#named-arguments
Isn't this more an issue with typescript? Doesn't your ide give you the declaration if you hover over the call?
> And I’ve seen real calls like this in production code: > updateSettings(user, true, false, true, false)
Really? He wants named parameters on all function calls cos he's got a memory like a sieve? This is a long solved problem to me
Perhaps, jsdocs might help here.
Someone want to recreate Smalltalk...