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

> 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 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:

   createUser (user, isAdmin => True, sendWelcomeEmail => False, skipValidation => True);

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.

In languages without compile-time keyword arguments but with block comments, you can use them inline for this.

   createUser(user, /* isAdmin */ true, /* sendWelcomeEmail */ false);

AI;dr: keyword arguments would be great in all languages, not just Smalltalk

Also, obviously bot/bought account.

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-...

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

Also known as ‘boolean blindness‘: e.g. https://cs-syd.eu/posts/2016-07-24-overcoming-boolean-blindn...

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.

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.

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:

  createUser(user, ~isAdmin:true, ~sendWelcomeEmail:false)

  createUser user ~isAdmin:true ~sendWelcomeEmail:false

  let isAdmin = true in
  let sendWelcomeEmail = false in
  createUser user ~isAdmin ~sendWelcomeEmail

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.

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)

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.

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

This needed an entire article?

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 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.

  setMenuState(MenuState.OPEN)
  setMenuState(MenuState.CLOSED)

[2] https://alexkondov.com/should-you-pass-boolean-to-functions/

i like to create enums instead of boolean.

CreateUser(CreateAdmin::enable);

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

Perhaps, jsdocs might help here.

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.

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.