<![CDATA[Carrot Games]]> http://community.carrot-games.com Smartfeed extension for phpBB <![CDATA[Langdev :: Re: On named arguments :: Reply by palas]]> 2026-03-09T06:37:33+00:00 2026-03-09T06:37:33+00:00 http://community.carrot-games.com/viewtopic.php?f=21&t=18&p=52#p52
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™?! :blobcatgiggle:

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 :blobcatnodfast:]]>
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™?! :blobcatgiggle:

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 :blobcatnodfast:]]> <![CDATA[Langdev :: Re: On named arguments :: Reply by celes]]> 2026-03-09T17:06:49+00:00 2026-03-09T17:06:49+00:00 http://community.carrot-games.com/viewtopic.php?f=21&t=18&p=53#p53
Functions accepting booleans??? Don't you know it's forbidden by Clean Code™?! :blobcatgiggle:
Ah, the teachings of Mr Uncle! :blobcatthink:

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! :blobfoxthinksmart:]]>
Functions accepting booleans??? Don't you know it's forbidden by Clean Code™?! :blobcatgiggle:
Ah, the teachings of Mr Uncle! :blobcatthink:

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! :blobfoxthinksmart:]]> <![CDATA[Langdev :: Re: On named arguments :: Reply by Sugui]]> 2026-03-10T18:45:07+00:00 2026-03-10T18:45:07+00:00 http://community.carrot-games.com/viewtopic.php?f=21&t=18&p=57#p57
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! :blobfoxthinksmart:
You are missing `DecisionUnsure`, not all decisions are easy to take. :pensivecat:

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. :dukeparty:]]>
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! :blobfoxthinksmart:
You are missing `DecisionUnsure`, not all decisions are easy to take. :pensivecat:

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. :dukeparty:]]> <![CDATA[Langdev :: Re: On named arguments :: Reply by Kampffrosch]]> 2026-03-12T09:56:49+00:00 2026-03-12T09:56:49+00:00 http://community.carrot-games.com/viewtopic.php?f=21&t=18&p=64#p64
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 :pensivepumpkin:]]>
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 :pensivepumpkin:]]> <![CDATA[Langdev :: Re: On named arguments :: Reply by celes]]> 2026-03-12T13:23:05+00:00 2026-03-12T13:23:05+00:00 http://community.carrot-games.com/viewtopic.php?f=21&t=18&p=66#p66

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

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