I find that many of these principles can be distilled (and replaced) by the simple adage: what is the best way to write this to make my colleague's life easier?
Get rid of those boolean function parameters (2015)
111–119 of 119 posts
Re: Get rid of those boolean function parameters (2015)
#112Earlier quoted context omitted.
Did you just skip over the beginning of the discussion, where everyone agreed that having a bunch of anonymous booleans is bad for readability, and circle back to advocating the status quo that everyone else is trying to improve on?
Everyone doesn't agree that this is bad for readability, and the status quo is the status quo for a reason.
Two, even. Two reasons:
1) Too many languages don't have native enumeration and set types to make a clean and elegant solution even possible.
2) Too many developers don't know how to do it, even if they use a language where it would be possible; some because they couldn't figure it out, but most probably just out of rote habit.
And yeah, sure, not quite everyone. But most, AFAICS. And I haven't seen any coherent argument against it from anyone actively claiming it's bad (Idunno, are there any besides you?), so feel free to try again and contribute something more convincing than your previous attempt.
Re: Get rid of those boolean function parameters (2015)
#113Earlier quoted context omitted.
I don't find it too bad to do interface IFunctionParameters { userId: string; name: string; age: number; } const example = ({userId, name, age}: IFunctionParameters) => {...}
The most annoying thing about this to me (and to be clear, I do exactly this all the time) is when you mouseover `example` at a use site, all you see is `IFunctionParameters`, not the definition of `IFunctionParameters`. At least in VS Code.
That's a good point, I've lost count of the times I've hovered my mouse over that IFunctionParameters tooltip expecting a nested tooltip to appear with the actual types
Re: Get rid of those boolean function parameters (2015)
#114There are a couple ways to approach it in Common Lisp, probably a few more than I have here. One, optional and keyword arguments can have defaults. (defun calc-formula (ia ib &optional (gain t)) ...) Two, you could use a dynamic variable and a closure. Outside the body of the let the gain var returns t, within the body of the let it returns nil. (defvar *gain-enabled* t) (defun calc-with-gain (ia ib) ...) (let ((*gai…
DEFVAR declares a variable to be special. That causes ALL uses of that variable to use dynamic binding. The function inside a LET with a dynamic variable does not create a closure. If one calls CALC-WITHOUT-GAIN later, there is no binding - unless there is another dynamic binding of that variable by a different LET active.
Thanks for correcting me. I know there is a way to do something similar to what I had in there, but I don't remember what it was. Any idea?
Re: Get rid of those boolean function parameters (2015)
#115Isn't this called Boolean Blindness?
Re: Get rid of those boolean function parameters (2015)
#116Earlier quoted context omitted.
No matter how smart the tool is, unless it can see the definition of the function, it can't guess the parameter name. Code is often shared on mail, chat programs etc, requring me to send compilable code snippets to get nice presentation out of a blob of text would be significant overkill...
Your IDE could automatically add those annotations as rich text or embedded HTML when you copy the source code out from the IDE into the E-Mail.
Would it be rich text when I copy to WordPad and HTML when I copy to a web page? Would it also support Markdown and maybe wiki ML? Would IntelliJ know that when I'm pasting code to an Emacs buffer in java-mode it should paste plain text, but when I'm pasting to an Emacs buffer that is an email, it should instead add org-mode annotations?
Overall this concept of copy/pasting with context is nice, but it only works for applications that have a defined API between them, such as MS Office OLE objects. In all other cases, pasting plain text is better than any "smart" solution.
Re: Get rid of those boolean function parameters (2015)
#117Earlier quoted context omitted.
> I don't care who invented it. It sounds fucking terrible. Sorry, but why should people care about what sounds terrible to you? > put some mashed potatoes in your rice and some pasta in a sandwich while you're at it If you weren't too obsessed with yourself, you'll know that that pasta actually exists, it's called "pasta e patate" and someone has put it in a sandwich for sure... there is also a very popular variant…
> Sorry, but why should people care about what sounds terrible to you? I never asked you to care what sounds terrible to me. Opinions are like assholes. Everyone has one, most are full of shit, and I don't really care if you don't like mine. If you supposedly don't care what I think, why bother trying to tell me my opinion is wrong? You can't have it both ways. > you weren't too obsessed with yourself, you'll know th…
> why bother trying to tell me my opinion is wrong?
Simple. Because you started it.
> Ok sure buddy. It's totally on me that a meal that may consist of entirely carbs is not common/popular outside of Italy. Totally my fault
Exactly it's totally your fault for being ignorant.
Pasta/rice with potatoes it's common in many "not born yesterday" cultures in places like China, India, Africa, not exactly a small percentage of the World population.
> would not seem appealing when other options are available?
You're still talking out of ignorance.
There were a lot of other options. Meat, for example, was common back then and of higher quality than today, but meat was sold for money, because rich people loved it.
> , it's a 3rd world problem because people can't afford (or can't adequately store) proteins, fresh vegetables
complaining about carbs it's a fictional problem white privileged people invented to feel special.
So, yes, it's a first World problem.
Also: I've said poor, not 3rd World, which, BTW, has been changed to developing countries.
The fact that American pilgrims, that were poor, haven't developed a balanced diet and starved to death or due to nutritional deficiencies, says a lot about the terrible diet they had back home and nothing about other cultures that did, at the same time, being equally poor.
Don't try put words in my mouth, please.
> you're bollocking on like it's a perfect meal
See?
You can't handle the truth.
I've only said you don't know what you're talking about.
Never said anything about the quality.
I, for example, don't eat pasta with potatoes but I do eat pizza and potatoes.
And am not a "monster".
> The difference is I am well aware that mine is an opinion
But you aren't aware that your opinion is also wrong, so technically you are making a mistake, I told you it, but don't wanna learn.
Tell me you come from a British colony without telling me.
> "the food of half a billion people is usually terrible, here come try some carbs on carbs."
Yes, exactly.
It is so terrible that they usually eat other culture's food.
You don't regularly eat haggis, Which is, BTW, sheep inside sheep, or shepherd’s pies, fish and chips, bangers and mash ..., do you?
Re: Get rid of those boolean function parameters (2015)
#118Earlier quoted context omitted.
The 'require named argument' solution is less strong than the enum solution. (An enum is also available in python). Indeed re-use of the plain bool in Python is less clear, as is passing it on. This makes the enum the best solution. However, enum is also a heavy-duty solution. It requires slightly more typing, but more importantly, it requires exporting an enum to all call-sites. Both in C++ and in python this is not…
It's worth noting that in Python, the enum will be slower than using a bool (how much slower? I don't know - I haven't measured it), if for no other reason than the repeated name lookups. Is it worth fretting over for something that's called occasionally? Probably not. If it's something that's going to be called a lot, e.g. in a tight loop, then it's something to be concerned about.
Another solution if you write fully-typed Python is to use typing.Literal:
calc(x, y, mode="gain")
def calc(
x: float,
y: float,
*,
mode: Literal["gain", "render"],
) -> float:
...
Re: Get rid of those boolean function parameters (2015)
#119Earlier quoted context omitted.
> You just moved the problem to a different layer. No, I think you're misunderstanding. Weird... Aha: My fault, sorry. > In your case you would end up calling your function like this: DoToppings(true, false, true, true); What?!? Heck no, that wasn't what I meant, why would you think that? [Goes repeatedly clicking "parent"] Aha, I see: Sorry, the threads and sub-threads have branched so I got confused as to where we…
Duh, I meant function MakePizza(Fillings: PizzaFillings); of course.
[deleted]