{"action":"created","issue":{"url":"https://api.github.com/repos/getify/FPO/issues/24","repository_url":"https://api.github.com/repos/getify/FPO","labels_url":"https://api.github.com/repos/getify/FPO/issues/24/labels{/name}","comments_url":"https://api.github.com/repos/getify/FPO/issues/24/comments","events_url":"https://api.github.com/repos/getify/FPO/issues/24/events","html_url":"https://github.com/getify/FPO/issues/24","id":410231094,"node_id":"MDU6SXNzdWU0MTAyMzEwOTQ=","number":24,"title":"Avoid abbreviated named arguments","user":{"login":"justsml","id":397632,"node_id":"MDQ6VXNlcjM5NzYzMg==","avatar_url":"https://avatars2.githubusercontent.com/u/397632?v=4","gravatar_id":"","url":"https://api.github.com/users/justsml","html_url":"https://github.com/justsml","followers_url":"https://api.github.com/users/justsml/followers","following_url":"https://api.github.com/users/justsml/following{/other_user}","gists_url":"https://api.github.com/users/justsml/gists{/gist_id}","starred_url":"https://api.github.com/users/justsml/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/justsml/subscriptions","organizations_url":"https://api.github.com/users/justsml/orgs","repos_url":"https://api.github.com/users/justsml/repos","events_url":"https://api.github.com/users/justsml/events{/privacy}","received_events_url":"https://api.github.com/users/justsml/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2019-02-14T10:29:33Z","updated_at":"2019-02-16T01:06:02Z","closed_at":null,"author_association":"NONE","body":"I wanted to float an idea to take advantage of additional benefits from destructured object param function signatures... But first I want to include my thoughts on the pattern.\r\n\r\nHere's an excerpt from an article I'm writing to explore the 'why' and trade-offs of this approach.\r\n\r\n------------------------------\r\n\r\n\r\nDestructured named object parameters is preferred to positional arguments **in almost every case.**\r\n\r\nInevitably, every design decision involves trade-offs. So, let me frame 2 priority goals, **clarity** and **memorability**, as more important than **extreme DRY** adherence. \r\n\r\n1. Clarity. Using the **same names** for function parameters AND in their invocations' arguments helps **cement the pattern deeper in the brain.** Flexibility in the key sequence lets you draw attention to contextually important parameters.\r\n1. Limit guessing game. Help people **read**, **evaluate**, and **understand** _usage examples & implementation_ code **faster,** while reducing need to repeatedly check the functions signature 😰(or relying on IDE features or keeping the docs open in another tab.) \r\n1. Improve Signal:Noise ratio. Positional arguments have virtually zero built-in indication of what each signifies. Related groups of names are naturally better \"anchor points\" in your brain.\r\n1. Better ergonomics for optional arguments (avoid needing to pass in an `undefined` argument).\r\n\r\nExceptions: There are a few use cases which I agree should be positional: for example the `copy` or `mv` file commands are a good fit for positional arguments. (A low, fixed arity tends to make things easier.)\r\n\r\n---------------------\r\n\r\n\r\nWith that considered, I feel argument names which are abbreviated or single letters are unnecessarily harder to memorize. Learning names is hard enough, and abbreviations invite too much confusion (common example are all over, see unix [`/usr` path was originally `UNIX source repository`, now it's `UNIX system resources`, not user](https://serverfault.com/a/137608/130829)). \r\n\r\nWhile it can be annoying typing `accumulator` in every reduce, it's unambiguous as it's not clear that an abbreviation would be `acc` instead of `accum`. Perhaps a non-standard term is a better fit on that one, say `results` or `state`. (This bit is a discussion for later...)\r\n\r\nIf single letter variables should be avoided in code generally (except in constructs like loops,) why are they ok in parameters when the knock-on effect is a leaky abstraction passing weirdness to every invocation.\r\n\r\n\r\nPlease let me know how you feel about my take.\r\nI really appreciate your time Kyle!\r\nThanks in advance!\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/getify/FPO/issues/comments/464266844","html_url":"https://github.com/getify/FPO/issues/24#issuecomment-464266844","issue_url":"https://api.github.com/repos/getify/FPO/issues/24","id":464266844,"node_id":"MDEyOklzc3VlQ29tbWVudDQ2NDI2Njg0NA==","user":{"login":"justsml","id":397632,"node_id":"MDQ6VXNlcjM5NzYzMg==","avatar_url":"https://avatars2.githubusercontent.com/u/397632?v=4","gravatar_id":"","url":"https://api.github.com/users/justsml","html_url":"https://github.com/justsml","followers_url":"https://api.github.com/users/justsml/followers","following_url":"https://api.github.com/users/justsml/following{/other_user}","gists_url":"https://api.github.com/users/justsml/gists{/gist_id}","starred_url":"https://api.github.com/users/justsml/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/justsml/subscriptions","organizations_url":"https://api.github.com/users/justsml/orgs","repos_url":"https://api.github.com/users/justsml/repos","events_url":"https://api.github.com/users/justsml/events{/privacy}","received_events_url":"https://api.github.com/users/justsml/received_events","type":"User","site_admin":false},"created_at":"2019-02-16T01:06:02Z","updated_at":"2019-02-16T01:06:02Z","author_association":"NONE","body":"1. i feel the behavior should follow something similar to #20 - _use 1st arg and don't throw_ or whatever is decided. (I know it's not the same so not 100% sure. Also it's an opportunity to show a warning in dev mode?)\r\n1. I haven't got enough info to even field a guess. Do you have a project discord/slack? Is there an alpha branch to float a trial balloon?\r\n\r\n"}}
{"actor":{"display_login":"justsml"}}