On named arguments

[celes]

I've just noticed an interesting usage pattern that has emerged for me over time wrt named arguments

I generally really like named arguments, so to me whether they belong or not in a language is not up for discussion. I couldn't care less about the issues frequently brought up, like "names become part of the public API" (so what? you're breaking your public API all the time anyway with named arguments or not) and my favourite non-argument: "I have python-induced trauma from libraries that abused named arguments" (you're not special we're all traumatized by python, your trauma is not language design).

Anyway, one place where named arguments shine is when functions take primitive parameters! It's not mandatory to set the name of the argument (well, depends on the language), but when a function takes a bunch of booleans, I find it almost always pays off in terms of readability to specify the names those parameters.

Maybe this is why people love those inlay hints so much? To me they're just distrtacting because having them *everywhere* means they become part of the background noise whereas placing them with intent where I think it adds value sounds like a way to get nicer and more readable code.

This is the bit of code that inspired this:

image.png (12.73 KiB) Viewed 138 times

It's obvious to me, and thus noisy, to know that the first two parameters are the "ui" and the game's "difficulty", which presumably the objectives hud will care about. Those are also well-typed things that would be hard to mess up, so I can skip the name and it's nice and succint.

For the third argument, though, it makes all the difference because it makes me go from being confused: "Why the heck does the objectives panel want to know about the pause menu??" to understanding a bit more about the system: "Ah, the objectives panel is only interactable when the pause menu is shown!".

[Sugui]

That is a great snippet of code to talk about named arguments and the inlay hints you mentioned!

I think inlay hints, for one side, can be really useful if the language doesn't support named arguments. Some very nice behaviour about these is that, if you pass a variable into a function parameter, and the variable name has the same name as the parameter, the hint hides itself.

Taking your code snippet as an example, imagine that your function definition was defined as this:

Code: Select all

function Draw(ui, difficulty, uiInteraction)

In the "ui" case, the hint would be hidden, since the variable is named exactly as the parameter.

In the "difficulty" case, I guess it depends on how the LSP is implemented or something for the editor, but personally trying out rust-analyzer in neovim, I get the hint hidden in the second case too! Because, it recognizes that the attribute of a structure has the same name as the function parameter, and so it hides the hint!

But yeah, as you said, I also think it's preferable to have more control about these, instead of depending on these hints. Also, with hints it gets trickier to navigate within the code, because you can miscalculate how many words or characters you need to move if there is a hint in between.

[celes]

but personally trying out rust-analyzer in neovim, I get the hint hidden in the second case too!

Ohh! I knew about the simple case (hiding when using a variable with the exact same name) but I didn't know rust analyzer had more advanced heuristics about this!

Nice

[palas]

but when a function takes a bunch of booleans, I find it almost always pays off in terms of readability to specify the names those parameters.

Functions accepting booleans??? Don't you know it's forbidden by Clean Code™?!

Anyway, named arguments are fantastic and Im beginning to miss them in Rust as much as I miss sum types in C#. The use case of combined named + unnamed args clearly shows how important it is to support using both in the same function.

I don't have much code examples as of now, but I guarantee you that I'll abuse the crap out of named arguments as soon as I'll be able to

[celes]

Functions accepting booleans??? Don't you know it's forbidden by Clean Code™?!

Ah, the teachings of Mr Uncle!

I know you don't need convincing, but you've made me think of how a lot of very experienced developers try to go on an spread their knowledge and most of them fail terribly because they fail to realize what is it that makes them good at programming. One of the universal truths in programming is that no amount of foresight can replae experience, so whatever their teachings are, often end up being misinterpreted.

I'm sure whatever sillyness the readers of Clean Code can conceive wasn't in the mind of the author. Writing is hard, hehe.

But, point taken! I'll make sure to declare a new heap-allocated class `Decision` with two inherited subclasses `DecisionYes` and `DecisionNo` with a method `makeDecision()` instead of using booleans next time!

[Sugui]

But, point taken! I'll make sure to declare a new heap-allocated class `Decision` with two inherited subclasses `DecisionYes` and `DecisionNo` with a method `makeDecision()` instead of using booleans next time!

You are missing `DecisionUnsure`, not all decisions are easy to take.

And where is the `DecisionFactory` class here? were you even thinking in creating a `Decision` calling its constructor directly? Decisions are complex and should be created by a factory class that instanciates them accordingly.

[Kampffrosch]

You joke, but it is really hard to convince people not to go down this path ("what if we need Y too") once they have decided on it.

I am always arguing for trying to make change easy instead of trying to make it unnecessary,
but I can't say I have had much success in convincing people where it mattered

[celes]

I really love how you put this: making change easy and not unnecessary!

When designing something you'll always get it wrong the first time, and having to deal with refactoring the bad abstraction is harder than if we started with no abstraction at all and a lot of usage code to learn from.

I always keep going back to this post by Casey Muratori, I know I repeat myself, but it's been such a great way to approach programming. Maybe I'm idealizing it a bit but I think it's a philosophy that avoids these pitfalls by default.