Hacker News Reader

Comment by xorcist | Hacker News Reader

Identifiers aren't short in C (or any other language) because disk storage is expensive but because readability suffers with long identifiers.

The example here is very much C-style (short, lowercase, underscore). The list of argument is called "args" (short and descriptive). It is not called argumentListArray.

It is not a coincidence that math have very short and well known identifiers. The rate of change in horizontal position is called x'. It is not called posHorizontalChangeRate simply because the latter is harder to read.

There is, of course, such a thing as having too short identifiers.

View on HN

Identifiers in C are short because expectations set by standard library which evolved when C had hard limit of 6 characters for externally visible symbols.

> 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.

I don’t personally find “arguments” any clearer than “args”. Not sure what’s gained by calling it arguments other than 5 extra characters.

Someone else gave these same examples but I find them compelling. Do you find atoi, strrchr or srand similarly clear? What about mbstowcs?

I wouldn’t call them similarly clear no. But that’s not really to pertinent to the question of args vs. arguments.

Its relevant in the context of the claim that c has short identifiers because "readability suffers with long identifiers", I dont really believe that the identifiers I listed were chosen with readability in mind.

How long haye you been programming? You got used to the short name and now it is a word to you.

That same argument applies to the word “argument”. What an “argument” is in the context of a function call is significantly more complex than the shorthand of “argument” vs “arg”.

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.

> If someone doesn’t know what it means the answer is

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.

If someone can’t deal with such totally standard and easily discoverable terminology, they don’t stand a chance. If they can’t ask their coworkers questions when confused, they (and the company) don’t stand a chance. You are far beyond the point of “balance” here.

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.

I don't think args is the right variable name to pick for this argument. As you say it is what that thing is called idiomatically. I think it is fine.

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.

If you work wit the code enough prsphi becomes as idiomatic as args. The question is which should be allowed to become idiomatic in the first place. Arguments is of course common enough across a lot of different projects that you can make a stronger argument that perhaps it should - and in fact it might be better as nobody thinks of the dictionary definition: "A discussion in which disagreement is expressed; a debate." when they see args.

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.

> 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?

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.

Hah :D I was confused why would you change the signature to parse integers when clearly I said it was parsing strings. Turns out you were not calling it "parse integer" but "parse international". I guess that's a point against that name then?

Try parse_intl_phonenum? One character longer than GP's.

Reply on news.ycombinator.com