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
If it is unclear what your one-argument function does, the name is the problem and you messed up, not the language. For multi-argument functions, you can have either enums or named arguments or, if you really have to, some kind of builder pattern thing: eatCheese(cheese().fromGoatMilk().withVanillaFlavor()).
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.
While I wish every language had them in a way, they do tend to enshrine the argument names in the ABI, so now you can't change those in public APIs. (Main reason I think it shouldn't be part of the ABI is because I think only the necessary things to identify and correctly use a contract should be part of the ABI)
I have been thinking off if there is a way to have it work without enshrining them in the ABI and my only real idea is: allow arbitrary names at the call site (e.g. `my_function(some_var=1)` or `my_function(some_var: 1)`) but don't enforce the naming, just have linting spit out a warning for it if it doesn't match.
I don't feel like anyone finds it onerous to not be able to rename functions as a non-breaking change, so it's not obvious to me that this is much of a deal-breaker. If anything, I'd be thrilled for it to force people to spend more time carefully picking the names of their parameters in public APIs so that the autocompletion/documentation popup in my editor has higher quality information!
Thinking more about this, I'm realizing that Swift was probably transitively inspired by Smalltalk; although I don't know much about Objective-C, my vague understanding is that it's a bit more inspired by Smalltalk's view of object-oriented programming via message passing than what commonly is considered OO nowadays (which is reflected somewhat in that it doesn't use the typical dot-operator for method calls), and I'm guessing that it was included in Swift as one of the things that was liked about Objective-C (and maybe a little to make interop more direct).
I don't remember where it was originally written, but Qt used to have a fantastic Qt Quarterly about API design that included "The Boolean Parameter Trap", which advised several potential solutions to this very problem. Of course, it was somewhat specific to C++ in what it recommended, but I find that many insights in Qt's API design are more broadly applicable than they may first appear. In this case one insight that stuck with me: it's often better to use an enumeration of two values over a boolean.
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.
You should just use objects/structs for function arguments when the arguments have any expectations of being expanded in the future. Use sane default behavior when new arguments/options are added to the function. Consumers of your interfaces will then have a much easier time handling updates down the line.
Named arguments are a great feature in Python. I often forget TypeScript doesn't have this, but I use the object form all the times. As a bonus, you can also declare these arguments in an object an interface type, aptly named.
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
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)
This is one of the things I've loved about Gleam, one local variable name and potentially an external label that callers can use to annotate themselves. For example, a function declaration may look like this:
pub fn pad_end(
string: String,
to desired_length: Int,
with pad_string: String,
) -> String
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:
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.
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'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.
so this article appears to be a story about a person who realizes their code was bad and also doesn’t know how to reverse lookup a definition? is that what this is? this is a genuine question cause that’s what this seems to reduce to
Even the premise is ridiculous, inlay hints for parameter names have existed for a really long time. What human using a code editor could come up with this "problem"? The comments all seem to be nodding along and even suggesting absolutely hare-brained code like "const isThing = true; ...". I feel like I'm losing my mind. How many interactions on this site are sill organic? Am I talking to a bot right now?
Bleep bloop. This has always bothered me for one. Bools for unnamed parameters just always end up a bit of a pain.
1. Somewhat often, parameter hints just stop working. Why? Who knows! There never seems to be any way to debug these mechanisms. They just stop working and you're forced to do stuff like delete random cache folders or toggle random options, as suggested by randos from Stack Overflow posts in 2017, until it maybe starts working again (for now)
2. Parameter hints sometimes aren't available when you need them. Xcode, for example, only seems to be able to put them inline, as text in the document that you replace with the arguments, something available only when writing code. You can't get them to pop up on demand as a reader as you can with, say, Visual Studio
3. You might be examining the code in some kind of review UI, rather than a code editor, in which case you're going to have to do some back and forth. You might be right in the middle of something yourself, and not in a position to retrieve the code locally to examine it in the usual editing environment. (I don't think you should go overboard optimising for this case, but I think it worth considering)
4. From the type checker perspective, all bools are equivalent. If you pass "false" for one bool parameter, then you could just as well pass that same "false" for another one - complicating rearranging or adjusting parameters, because, depending on the type of change you make, you may not get a good set of diagnostics to work through. And it gets worse if you've got defaulted or optional parameters
yeah, I immediately came to the comment section to look for inlay hints, and your comment is the only one that mentions them. I guess many people might not be aware that they're a standard editor option?
fwiw, while inlay hints are great, they don't work in either git-delta or github, so they're not availabe in a good chunk of the places that I'm looking at code, so for TypeScript, I do lean towards object arguments with keys the way the article suggests.
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?
setMenuVisible()
If it is unclear what your one-argument function does, the name is the problem and you messed up, not the language. For multi-argument functions, you can have either enums or named arguments or, if you really have to, some kind of builder pattern thing: eatCheese(cheese().fromGoatMilk().withVanillaFlavor()).
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.
[dead]
AI;dr: keyword arguments would be great in all languages, not just Smalltalk
Also, obviously bot/bought account.
Swift also has them. It's probably the one thing I sometimes wish Rust would copy from them.
While I wish every language had them in a way, they do tend to enshrine the argument names in the ABI, so now you can't change those in public APIs. (Main reason I think it shouldn't be part of the ABI is because I think only the necessary things to identify and correctly use a contract should be part of the ABI)
I have been thinking off if there is a way to have it work without enshrining them in the ABI and my only real idea is: allow arbitrary names at the call site (e.g. `my_function(some_var=1)` or `my_function(some_var: 1)`) but don't enforce the naming, just have linting spit out a warning for it if it doesn't match.
I don't feel like anyone finds it onerous to not be able to rename functions as a non-breaking change, so it's not obvious to me that this is much of a deal-breaker. If anything, I'd be thrilled for it to force people to spend more time carefully picking the names of their parameters in public APIs so that the autocompletion/documentation popup in my editor has higher quality information!
Thinking more about this, I'm realizing that Swift was probably transitively inspired by Smalltalk; although I don't know much about Objective-C, my vague understanding is that it's a bit more inspired by Smalltalk's view of object-oriented programming via message passing than what commonly is considered OO nowadays (which is reflected somewhat in that it doesn't use the typical dot-operator for method calls), and I'm guessing that it was included in Swift as one of the things that was liked about Objective-C (and maybe a little to make interop more direct).
This is commonly referred to as "the boolean trap". You'll find lots of articles about it.
This one is a classic,
Avoid the Long Parameter List
https://testing.googleblog.com/2024/05/avoid-long-parameter-...
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.
I don't remember where it was originally written, but Qt used to have a fantastic Qt Quarterly about API design that included "The Boolean Parameter Trap", which advised several potential solutions to this very problem. Of course, it was somewhat specific to C++ in what it recommended, but I find that many insights in Qt's API design are more broadly applicable than they may first appear. In this case one insight that stuck with me: it's often better to use an enumeration of two values over a boolean.
And while searching for a reference, I found the original Qt Quarterly, archived here: https://doc.qt.io/archives/qq/qq13-apis.html - I am sure some of it is just hopelessly outdated, but the general insights probably still hold up. There's a probably-more-modern successor here on their wiki: https://wiki.qt.io/API_Design_Principles
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.
You should just use objects/structs for function arguments when the arguments have any expectations of being expanded in the future. Use sane default behavior when new arguments/options are added to the function. Consumers of your interfaces will then have a much easier time handling updates down the line.
Named arguments are a great feature in Python. I often forget TypeScript doesn't have this, but I use the object form all the times. As a bonus, you can also declare these arguments in an object an interface type, aptly named.
Amen. Was about to comment:
create_user(user, is_admin=True, send_welcome_email=False);
Not even article-worthy.
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):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:
This is one of the things I've loved about Gleam, one local variable name and potentially an external label that callers can use to annotate themselves. For example, a function declaration may look like this:
And a call to this function may look like: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 "
You can do this as a convention in javascript since 2015, but I haven't seen a library that does it:
C# has that
This is why I continue to advocate for using Ada. It's not just about memory safety but conscious effort was put into readability.
Calling the procedure in the article in ada would simply be:
Named arguments are supported very widely. How is this an argument specifically in favor of Ada?
In languages without compile-time keyword arguments but with block comments, you can use them inline for this.
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 is one of the numerous advantages of Swift: arguments are labeled.
This very matter is covered nicely in Code Complete.
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'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.
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.
Can you imagine how much fun it would be to find that bug?
so this article appears to be a story about a person who realizes their code was bad and also doesn’t know how to reverse lookup a definition? is that what this is? this is a genuine question cause that’s what this seems to reduce to
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
This needed an entire article?
Only because the language that's used doesn't support named/labeled arguments.
This article relates to two classic principles:
1. Avoid long parameter lists [1]
2. Avoid boolean arguments [2]
For #1, long parameter lists should be named (named arguments, options object, etc).
For #2, and booleans should be replaced by meaningful enumerations.
> toggleMenu(true); That’s clear enough. the meaning is obvious
Actually, it's incredible ambiguous. Is that toggling the menu? Or setting it to the open state? Or something else? I have no idea.
[1] https://testing.googleblog.com/2024/05/avoid-long-parameter-...[2] https://alexkondov.com/should-you-pass-boolean-to-functions/
I was thinking the same.
ToggleMenu(); should do it. Or is there something I'm missing? Ie is the function misnamed? OpenMenu(true); maybe what the function is doing?
Must be the latter, IMO
Perhaps, jsdocs might help here.
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
i like to create enums instead of boolean.
CreateUser(CreateAdmin::enable);
Someone want to recreate Smalltalk...
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.
Even the premise is ridiculous, inlay hints for parameter names have existed for a really long time. What human using a code editor could come up with this "problem"? The comments all seem to be nodding along and even suggesting absolutely hare-brained code like "const isThing = true; ...". I feel like I'm losing my mind. How many interactions on this site are sill organic? Am I talking to a bot right now?
Bleep bloop. This has always bothered me for one. Bools for unnamed parameters just always end up a bit of a pain.
1. Somewhat often, parameter hints just stop working. Why? Who knows! There never seems to be any way to debug these mechanisms. They just stop working and you're forced to do stuff like delete random cache folders or toggle random options, as suggested by randos from Stack Overflow posts in 2017, until it maybe starts working again (for now)
2. Parameter hints sometimes aren't available when you need them. Xcode, for example, only seems to be able to put them inline, as text in the document that you replace with the arguments, something available only when writing code. You can't get them to pop up on demand as a reader as you can with, say, Visual Studio
3. You might be examining the code in some kind of review UI, rather than a code editor, in which case you're going to have to do some back and forth. You might be right in the middle of something yourself, and not in a position to retrieve the code locally to examine it in the usual editing environment. (I don't think you should go overboard optimising for this case, but I think it worth considering)
4. From the type checker perspective, all bools are equivalent. If you pass "false" for one bool parameter, then you could just as well pass that same "false" for another one - complicating rearranging or adjusting parameters, because, depending on the type of change you make, you may not get a good set of diagnostics to work through. And it gets worse if you've got defaulted or optional parameters
yeah, I immediately came to the comment section to look for inlay hints, and your comment is the only one that mentions them. I guess many people might not be aware that they're a standard editor option?
fwiw, while inlay hints are great, they don't work in either git-delta or github, so they're not availabe in a good chunk of the places that I'm looking at code, so for TypeScript, I do lean towards object arguments with keys the way the article suggests.
The comically unncessary section headers are also incredibly LLM coded.
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.
[dead]