> The list of argument is called "args" (short and descriptive)
You’re proving the original point - it should be named “arguments” because that is what it is.
Saving … 5 bytes? by naming it “args” instead is exactly OP’s point.
You’re proving the original point - it should be named “arguments” because that is what it is.
Saving … 5 bytes? by naming it “args” instead is exactly OP’s point.
In any case, I can remember when I started programming and no I didn’t have any problem remembering that arg is short for argument. I’ve seen acronyms and shortening of words all my life before programming after all. However I do remember being confused by the concepts argument or keyword argument in the abstract.
Short said, I really think this is making a mountain of a molehill. If someone doesn’t know what it means the answer is “arg is short for argument” and then you move on.
Who do they ask? They have just interrupted someone else's flow to ask - worse they might ask the wrong person and interrupt more than one persons flow in getting an answer. There is a high cost to even trivial questions and the more of them someone needs to ask the worse.
The point is there is a balance you need to find that balance.
I take pedagogy very seriously and work very hard for both experienced and inexperienced people to understand what I do, but this is just ridiculous. This is a non-issue.
It is more about if your code needs to parse an internationaly formated phone number from a string into a struct. (or pick anything else specific only to your problem domain) How do you call that function? Do you call it prsphi? (prs for parse, ph for phone number and i for international) Or do you call it parse_international_phone_number? Or maybe international_phone_string_to_phonenumber_struct? (or something similar in CamelCase)
That is where the difference starts to matter. And I for one don't want to read code with many prsphi's around.
I have never worked with phone numbers outside of a class assignment so prsphi is not something I would understand. However if I was in a codebase that worked with phone numbers often I'd probably get to know it and like the shortness.
That's a false dichotomy; you could call it for instance parse_int_phonenum, abbreviating "international" and "number" to the still understandable "int" and "num" (and smashing together "phone number" into "phonenum" since it's a single concept in this code base). It's nearly half the length of your suggestion, while still being understandable at a glance.