Timeline for Should one always know what an API is doing just by looking at the code?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 3, 2014 at 16:54 | comment | added | Doval | @Bakuriu You're right, of course, but booleans are particularly bad offenders because "true" and "false" have no meaning in and of themselves. A boolean has no context on its own, whereas even a two-valued enum provides context (e.g. ENABLED and DISABLED). I will point out though that "enforced named parameters" are just records, so the argument type isn't quite a naked boolean any more; it's a record containing a boolean. | |
| Jun 3, 2014 at 16:50 | comment | added | Raphael | Yay for using stronger type systems! That said, the answer from the title can definitely answered with "no" -- that's what comments are for! | |
| Jun 3, 2014 at 16:48 | comment | added | Bakuriu |
@Doval I don't get what you are trying to saying. I used booleans in that situation simply because the OP used them, but my point is completely unrelated to the value passed. For example: setSize(10, 20) isn't as readable as setSize(width=10, height=20) or random(distribution='gaussian', mean=0.5, deviation=1). In languages with enforced named parameters booleans can convey exactly the same amount of information as using enums/named constants, so they can be good in APIs.
|
|
| Jun 3, 2014 at 12:41 | comment | added | Doval | @Bakuriu Even C has enums, even if they're integers in disguise. I don't think there's any real world language where booleans are good API design. | |
| Jun 3, 2014 at 11:56 | comment | added | user11153 | It's known as "boolean trap" | |
| Jun 3, 2014 at 11:06 | comment | added | Ven | Agreed - let's stop using booleans :) | |
| Jun 3, 2014 at 9:44 | history | tweeted | twitter.com/#!/StackProgrammer/status/473762113064673282 | ||
| Jun 3, 2014 at 8:43 | comment | added | Bakuriu |
This is precisely the reason why some languages have named parameters (sometimes even enforced named parameters). For example you could group a lot of settings in a simple update method: foo.update(pinned=true, globally=true). Or: foo.update_pinned(true, globally=true). So, the answer to your question should take also the language features into account, because a good API for language X might not be good for language Y and viceversa.
|
|
| Jun 3, 2014 at 5:07 | answer | added | BenM | timeline score: 27 | |
| Jun 3, 2014 at 4:54 | answer | added | Frank | timeline score: 6 | |
| Jun 3, 2014 at 4:50 | history | edited | markmnl | CC BY-SA 3.0 |
added 15 characters in body; edited title
|
| Jun 3, 2014 at 4:27 | history | asked | markmnl | CC BY-SA 3.0 |