7 ms·
Alternate title: "Unnamed parameters considered harmful" Alternate (better) solution to the author's problem: Use enums
by fyolnish 11y ago
Alternate title: "Unnamed parameters considered harmful"
Alternate (better) solution to the author's problem: Use enums
- mpweiher 11y agoAlternate (better) solution to the author's problem: Use a language where all parameters are named, like Smalltalk or Objective-C. document addObserver:observer forNotificationNamed:'load' isWeak:false. xhr openURL:options url type:options type async:options sync negated
- Argorak 11y agoBut even there, I would prefer: [document addWeakObserver: observer forNotificationNamed: 'load'] and [document addObserver: observer forNotificationNamed: 'load'] Assuming for a second, that the non-weak observer should be the normal case.
- BurningFrog 11y agoSo wordy and repetitive and wordy.
- jjoonathan 11y agoNot a problem if autocomplete is working.
- exDM69 11y agoThe issue with autocomplete is that it makes writing a lot of code really easy but offers no help when reading the code. Syntax/semantic highlighting may help a little but the issue is still there. Given that more time is spent reading than writing code, autocomplete is only a partial solution to this problem.
- yoz-y 11y agoI consider verbose code to be more readable in general. However one has to take more time when naming their functions and parameters.
- mpweiher 11y agoThis comment makes sense for the original problem, but not for the message you're replying to, as keyword parameters help tremendously with readability.
- BurningFrog 11y agoI've never worked in those languages, but I suspect I'd end up with a lot code like this: foo(author: author, title: title, price: price) The problem in the article is real, but it is the exception. If it's hard to see what 5% of your parameters mean, forcing 100% of them is probably a cure worse than the disease. When I worked in Java with IntelliJ, the solution was to simply hover over the call, and the declaration would appear.
- jjoonathan 11y agoIDEs fix both problems: writing verbose code and reading terse code. The thing is, code isn't always examined in a working IDE, and it tends to be read outside of an IDE more than it tends to be written outside of an IDE. The disease is far worse than the cure. I frequently (at least once a day) find myself wishing code was written in the smalltalk style but I've only found the smalltalk style inconvenient on a small number of occasions.
- mpweiher 11y agoWhile I can't speak to what you would end up with, my experience (~quarter of a century) is that this is not the case. To verify, I just did ack '\[.*:' | less to search my code-base for message sends with parameters. Scanning the first hundred or so results shows the pattern you mention to be rare. Dan Ingalls explains the syntax really nicely in this video: https://youtu.be/P2mh92d-T3Y?t=600 With this type of syntax, most APIs turn into EDSLs all by themselves, and often read like fairly natural sentences. I ramble on a bit about the relationship between keyword syntax and (lack of) operator overloading: http://blog.metaobject.com/2015/03/why-overload-operators.html
- fyolnish 11y agoSo memorable.
- bbcbasic 11y agoMuch bugfree
- 1wd 11y agoAlternate (even better) solution: Use a language where you can optionally name parameters, like C#. xhr.OpenUrl(url, async: true);
- gmac 11y agoActually, even in Objective-C it's technically optional to give your parameters names. Feel free to knock yourself out with method signatures like: - (void)doMysteriousThingsWithParameters:(int)x :(BOOL)y :(NSString*)z; I've come across this recently when creating an HTML5 <canvas> context object to be called from within JavaScriptCore. This needs to expose JS-friendly methods like: - (void)strokeRect:(CGFloat)x :(CGFloat)y :(CGFloat)w :(CGFloat)h; - (void)arc:(CGFloat)x :(CGFloat)y :(CGFloat)radius :(CGFloat)startAngle :(CGFloat)endAngle :(BOOL)antiClock;
- 1wd 11y agoInteresting. I don't use Object-C, but always heard parameter names are actually considered to be part of the method name there. Was that wrong? Ah, or do you mean the name is just empty? How does that work on the implementation side? I.e. how do you refer to the passed arguments?
- fyolnish 11y agoParameters don't have names, the message has a format, and th only rule of that format(referred to as a "selector") is that parameters are preceded by a :
- anton_gogolev 11y agoMore, more parentheses!
- _ZeD_ 11y agotoo much verbose. I prefer python approach, where you can set "optionally named" and "kwarg only" parameters" on a per function basis. For a description, see https://www.python.org/dev/peps/pep-3102/ https://www.python.org/dev/peps/pep-3102/
- jjoonathan 11y agoOh come on, we both know that if you give people a choice the feature will be underused. If you want proof just look at python code!
- _ZeD_ 11y agoI don't understand. What you mean?
- ExpiredLink 11y ago> Use enums For internal but not external APIs. Enums create tight coupling and are not extensible. Booleans and Enums should be avoided for external APIs.
- fyolnish 11y agoWhat are you talking about? How is using an enum more tightly coupled/less extensible than a function name?
- lclarkmichalek 11y agoI usually don't care if my booleans are extensible or not.
- twic 11y agoWell that's just a lack of ambition on your part: http://thedailywtf.com/articles/What_Is_Truth_0x3f_ http://thedailywtf.com/articles/What_Is_Truth_0x3f_
- twic 11y agoOh man, i should not have started reading DailyWTF. When booleans attack: http://thedailywtf.com/articles/tri-state-boolean http://thedailywtf.com/articles/tri-state-boolean http://thedailywtf.com/articles/Special-Delivery http://thedailywtf.com/articles/Special-Delivery
- rdfi 11y agoInstead of booleans or enums why not have different methods for each value of the bool/enum, e.g.: openAsync(...), open(...)
- skwirl 11y agoInstead of having different methods like open/openAsync why not have enums?
- ygra 11y agoDifferent names don't scale well beyond a single boolean argument.
- barrkel 11y agoI've seen this in practice a lot in jQuery and many people with jQuery experience. You end up with methods like showFoo / hideFoo, enableFoo / disableFoo, and then you have to continuously write if-statements like this: if (someCondition) { showFoo(); } else { hideFoo(); } Instead of: setFooVisible(someCondition); The point being, creating lots of different methods for each variant reduces one's ability to use other abstraction tools, like variables, to control parameters.
- chriswarbo 11y agoFunctions are first-class values, so what's wrong with: (someCondition? showFoo : hideFoo)(); You can also pass in arguments if they both accept the same parameters, eg. (someCondition? show : hide)(foo, duration);
- masklinn 11y agoExcept they're methods so you have to write (someCondition ? foo.show : foo.hide)(); except the language does not auto-bind so you have to write (someCondition ? foo.show : foo.hide).call(foo); or maybe (someCondition ? foo.show.bind(foo) : foo.hide.bind(foo))();