Hacker News Reader

Comment by tom_mellior | Hacker News Reader

This looks cool, but I dislike the naming. Calling a queue "queue" would be so much more readable than "que", and so on. I think the everything-is-three-letters gimmick is overall a drawback. Also, would it really hurt that much to write "#define PRIMITIVE" instead of "#define P"?

View on HN

I've found that in forums like this, people generally react badly to comments about naming, but I've found that it actually matters more than people think it does.

Many things have exactly one correctly spelled full name, but many alternative contractions or cute variations.

Programmers can be expected to know the correct spelling of "vector" or "dequeue". They can't be expected to know your specific contraction or abbreviation of it. They can't guess and they're not mind readers. They have a muscle memory that has them type out the full word automatically, without thinking.

Don't break these expectations.

I mostly agree with this comment except “dequeue” is a bad example. C++ has called this data structure “deque” (pronounced deck) since the beginning of the STL. Is there another language/library that spells it dequeue?

> Is there another language/library that spells it dequeue?

Yes.

  https://www.npmjs.com/package/dequeue
  https://api.jquery.com/dequeue/
  https://docs.microsoft.com/en-us/dotnet/api/system.collections.generic.queue-1.dequeue?view=net-5.0

.NET uses Dequeue as a verb, not a noun though.

Perhaps that's another reason to call the data structure a "Deque" since "Dequeue" is already used for the verb meaning "to remove an item from a queue."

It's also for a completely different purpose, but I was answering about the spelling as a direct answer to a question.

For better or worse, Rust calls it a VecDeque, but I think this is meant to clarify that the structure is just Vec storage with some extra methods on top to provide convenient ring buffer usage patterns:

https://doc.rust-lang.org/std/collections/struct.VecDeque.ht...

https://docs.oracle.com/javase/7/docs/api/java/util/Deque.ht...

Common Lisp is a truly awful offender in this regard, with "cute" slightly-abbreviated opaque names for subtly-varying concepts.

EQ/EQL/EQUAL/EQUALP, PROCLAIM/DECLAIM/DECLARE, and the atrocious PAIRLIS (really??). And not to mention the fact that PAIRLIS returns an association list, which is entirely different from a "plist".

And then of course CAR, CDR, CADR, CDDR, et alia.

This is all second nature for an experienced Lisp programmer, but it makes for a difficult learning experience.

You are correct. But more important is internal consistency - and adherence to the consistency rules of the eco-system. This allows to deduce naming of API-Elements after a while. So the most important rule is- do not be creative. Think like a bureaucrat, adhere to the standards and the ecosystem around you.

I hate this field so much. That anyone creative chooses willingly to go into software is a miracle. Are there people out their with pre-broken spirits, that want to join this soul-less galley of horrors? Starvation should be preferable to this. But i digress..

Why not make naming something that can be personalized? Make the variablename a sort of rule-based-building-block-lego-system, that can be adapted by the user.

Increment+Variable -> "upIndex" for you Increment+Variable -> "incVar" for me. Everyone is happy, the frameworks and apis only specify the buildingblocks as variableNames.. autotranslated variableNames, customized to everyones flavour.

Hooray, i contributed. Prolonging the nightmare.

I've had the opposite complaints on my similar but verbose library. Some want short names and some want full explicit names.

I'm not sure which way is more popular. Paul Graham has mentioned in several essays how programmers are lazy and want to type the minimum number of characters possible. On the other hand Elon Musk has loudly complained about acronyms and contractions.

In the end you can't please everyone, so the developer just has to pick a style and go with it. If you dislike the short names, it's easy enough to put a comment above the template instantiation explaining what's going on.

I mean, one can (and I will argue "should", though I appreciate many people will be angry about this) used macros to change the names to whatever they want... but this makes a lot more sense if libraries stick with full names and the contractions are house style.

I think a lot of this has to do with what people develop with. If they are a vim person then typing long names is annoying, but if they use any type of IDE, the autocomplete removes that hassle and the benefits of having a clearer naming convention can shine.

In case anyone reading doesn't realize, Vim can do keyword completions. It isn't automatic, but out of the box, you can press ctrl+n to move through a list of possible completions.

Not as elegant as some IDEs I'm sure, but if typing is stopping you from using longer names, this could help.

Also, for IDE style completion:

https://github.com/ycm-core/YouCompleteMe

People confuse 'verbose' and 'clear'. Long names make my eyes glaze over as a reader.

Vim has autocomplete too. This is not an argument about vim since I have seen vim users employing both conventions.

Graham seems like he'd be much more authoritative on this topic than Musk.

I think in this case it’s largely a matter of taste. I actually like the everything is three letters thing. It feels clean, and personally I can still read and understand each abbreviation.

I do actually agree on the primitive vs p thing though...

Another advantage of #define PRIMITIVE - it doesn't steal a handy 1-char identifier that the consuming program might want to use for its own purposes. And as well as making a longer identifier, I'd also personally suggest also adding a library-specific prefix, to further reduce the risk of conflicts.

(I have worked on code where the debug print macro was called P...)

The three-letter names have the advantage that it makes the function names shorter since they are prefixed with the same letters.

Reply on news.ycombinator.com