Hacker News Reader

Yes, many useful names are short: point, input, output, x, y, z, origin, r, g, b, alpha, color, vector, pi, string, file, buffer, open, close, print, format, copy, move, list, load, run, id, pop, push, stack, context, env, user, draw, update, refresh.

Also, notice how R, G, and B have a very clear meaning when put near "color"? Context is a thing our brain manages very well.

There's also the implicit assumption of underlaying knowledge. I remember writing some graphics routines and looked at some examples, but they always seemed to consist of a mess of single variable names. After reading up on the theory it became clear that they were all the conventional mathematical constants used in the formulas to derive the algorithm. If you were intimate with the math these names would be the obvious choice, yet if you were an outsider they would seem indecypherable. I now prefer to use simple english terms and put the math terms next to them as a comment, rather than the other way around. A caveat is that actual formulas might become a bit lengthy.

Many of those short names are keywords (or pre-defined identifiers) in many programming languages, e.g. string, close, print, copy in Go. Having to use another name instead can also be difficult.

Poetry time:

    (let ((copy (copy-list list)))
      (list copy 'copy 'let))

A 13 syllabic verse (7+6, with caesura)

(but yes, you are right)

FWIW, I never have really found the ambiguity caused by using the same symbol as both a variable and a function to be a readability problem: I think people are generally pretty good at things like noun/verb ambiguity and so this kind of ambiguity sort of "clicks" with us.

What has bitten me many times is accidentally overwriting a builtin function like max or len in python and then scratching my head about the strange errors that result from this.

Overwriting is not so much a problem of naming than one of dynamic updates: some environments do actually display a warning when you change a global binding, which helps.

That helps, but I find that a Lisp-2 like Common Lisp (I.e. A language with different namespace for variables and functions) is a more intuitive programming environment than languages with a single namespace.

I prefer Lisp-2 too.

I'm extremelly well informed about Lisp-1 versus Lisp-2. I chose Lisp-2 for my own Lisp dialect, with special support for working in the Lisp-1 style: there is a way to code with higher-order functions without ever using the dialect's equivalents of the funcall function or function operator. I thereby consider the Lisp-1 vs. -2 question to be a solved problem.

The requirements which drive the preference for either are all valid. I, the designer, have simply taken both requirements and integrated them. Of course, requirements like, "I want to use list as a variable name without shadowing the lisp function" directly conflicts with "I want to reference functions and variables the same way without function or funcall". However the conflict can be confined down to the argument list of an individual form. I.e. "Sure, you can have both, just not in the argument list of the same form."

Incidentally, I've been using TXR a bit for text-processing recently, it's generally been pretty nice once I've figured out what exactly needs to be done to get the matching to work, but the various failure modes for the pattern language aren't very intuitive.

I don't disagree. If debugging that sort of thing were intuitive, we'd all be coding in Prolog. It's like an invisible "if" hidden in every statement which branches elsewhere if there is no match. @(assert) can help; if you know that something that follows must match, you get an exception if it doesn't. I used asserts in the man page checker:

http://www.kylheku.com/cgit/txr/tree/checkman.txr

I've gotten the habbit of removing the last vowel in those cases. Not always pretty but when documented it's pretty transparent.

If you're processing an HTML form then 'name' could be the form name attribute, the input element name attribute, the person's name, the person's username, the person's identifier within the application or database, and so on. Try reading some badly written PHP form handling code where the logic and the HTML are in the same script and you see this precise problem.

This is definitely a problem when you mix different semantic concerns in one level of code.

Doctor, it hurts when ...

Surname is only seven letters and it doesn't suffer those problems

It suffers a different problem though: Name implies your given name, possibly including your family name. Surname is much more specific (family name only) and thus not suitable in any case where that's not what you meant.

This is not an easy problem to solve. For every "easy" example of a good name, one readily encounters an easy counterexample that renders the name ambiguous or unfit for a particular purpose.

Names must necessarily include context to be meaningful. If "name" is an unambiguous identifier in your scope and it's obvious what it does, great! Don't fix what isn't broken. But when you catch ambiguity or uncertainty, revisit the code, so future developers have an easier time understanding what you meant.

> It suffers a different problem though: Name implies your given name, possibly including your family name. Surname is much more specific (family name only) and thus not suitable in any case where that's not what you meant.

And this digs out a tangential problem - that often, "name" is as specific as you can get (or at least as specific as you should get) - http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b....

I like the rule-of-thumb that short identifiers are fine if their context is limited in length - particularly if proper lexical scoping is supported. Humans do context very well, and imposing some arbitrary length limit ignores this.

This is important.

When you're inside a function, dealing with very limited scoped variables, people get that.

People also 'get' attributes of classes and can grasp that context.

You know what's rational - that the 'length' of an array is just called 'length' :)

Anything else would be missing the point.

I would argue that "name" by itself is actually quite a bad name. What is it naming? It should "firstName" or "databaseName", etc.

I have learned over many years that longer, highly readable and descriptive names make life extremely easier in the long run, at the expense of a few extra characters to type.

Surely the context it's in would help you understand whether its referring to a person or a database?

So many unreadable and confusing code bases exist precisely because people made that assumption.

For example, in the case of "name" there are typically many different things that need a "name" in the same context. First name, last name, etc. "name" by itself (and other short names) is honestly asking for lots of headaches in the long run.

The CRUD database tables I make usually have "id" and "name" columns. "name" is always a human-readable descriptive string (few words). No need to have a more specific name for what "name" is.

If you write SQL, you can disambiguate by table name prefix. If you iterate over result sets for example in python, you can easily be more specific on tuple destructuring time ("for personName, carName in ...").

When defining a table "Person", I consider it bad style to prefix all column names with "person". Btw this overzealous disambiguation falls flat as soon you do a self-join.

A DB has a lot more obvious and strict context than a file of source code, and the law of demeter typically doesn't affect DB contexts as much as it does code, in practice.

In real code, it's unwise to expect the reader to study context just to parse a name.

Are you agreeing with me here? I think so but can't tell for sure...

I'm saying that a DB's organization is not the same as that of source code, and that surrounding context is a fundamental part of working with a DB and reading its layout, so perhaps the naming rules can be relaxed a bit in some cases.

>The rule against identifiers shorter than 8 characters specifically disallows `name', which makes absolutely no sense to me. This particular word says a lot, and it can easily have its context implied with no problems. Example, if we're working on a database that stores people's personal information, it's easy to guess what `name' means.

Is it "first name", "last name" or "full name"?

'name' is the one worst variable names possible. Its like calling your program 'program', your function 'function'. There is always a better choice.

Depends on the context. If other vars are 'addess' and 'phoneNumber', 'name' looks pretty reasonable.

Hardly.

Is it a person's full name? legal name? first name? last name? nick name? desired call name? a company name? the name (alias) of the stored address?

If you're digging into that specific meaning of the word "name" (as a property of a person), you're likely doing something wrong:

http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...

> If you're digging into that specific meaning of the word "name", you're likely doing something wrong:

If you're not you're definitely doing something wrong.

> (as a property of a person)

The original comment does not specify that it's "a property of a person". It could be a company, it could be a non-specific delivery address, etc...

legal name in which country? name order varies between UK and China. What's a "call"? Whose company? what kind of address?

Following this line of thinking, communication is impossible because everything is ambiguous.

> Following this line of thinking, communication is impossible because everything is ambiguous.

And making everything as ambiguous as possible makes communication easier… how?

When I taught programming to freshmen, the example I used to use when they called variables "number" or "string" was: "that's like calling your baby 'baby'."

People do that and in many situations it's the most suitable choice.

Why would anyone downvote this? Without any comments? Did you never say or hear "the baby is crying"?

I will now end my concern about being downvoted and get a life. The discussion culture in this thread is mad.

I didn't downvote, but what I really meant is "giving your baby the name 'Baby'".

Very fair - thanks for the update. Maybe it helps to think not as giving variables fixed names (like Luke or Lisa) but seeing them as data accessed by descriptors that describe their qualities (the ones that matter in the current context).

Btw humans also have many names, depending on context. You might have had funny nicknames in your childhood, your friends speak to you by your first name, other might speak to you by your last name, others might call you "darling" etc... likewise it's also not totally uncommon to speak to babies by the handle "Baby", like "how are you doing Baby?".