I work in one of the magnificent seven and the culture here is codename crazy. Everything has code names, of course: every project, every release of every project, every component or subservice of every project, every internal tool, and often minor features that address some one-off problem in any of the above.

I am sure that these names solve some kind of brevity problem for the people on those immediate teams, but it is a nightmare for everyone else.

It is impossible to reason about or even understand have the statements made by members of other teams in a meeting or communication because every other word they use is a code name for something that you’ve never heard of and the name doesn’t bear any resemblance to what it represents. It drives complexity through the roof.

The CTO at some point later on decreed "enough; descriptive names, not made up things" … and the experience was such that I agreed with the decree, and I've sort of felt that way ever since. I've given a few names sparingly to a few things, but mostly a.) they have some connection to the named thing and b.) I reach for it when the purpose isn't clear yet and thus "descriptive" can be hard to come by.

You could have named it a "PoMo" (portmanteau of position-move), if you're tired of typing.

I'm also a bit surprised since the examples are Rust? Some of the naming is sort of "Hungarian notation"-esque. Why not let the type carry that information, and strike it from the name?

The human brain finds unexpected or weird words a lot more memorable than expected words.

grep is better than find "find-regular-expression"

awk is better than "execute-command-on-regular-expression"

perl has nothing to do with pearls

If it's a common command, concept, function, etc. that appears in may places, give it an odd name!

Document it thoroughly!

And don't go overboard. When everything is special, nothing is, with the added disadvantage that nothing is "readable" either.

The nature of code is that it is communication: it communicates action to the computer and behavior to the reader. Variable names are not for the computer, they are for the reader, so, whenever possible, the names we use should be meaningful to the reader.

If the name requires specialized knowledge, such as "what does this name mean," it is lingo, which is sometimes necessary, but should be regarded as a smell, as it is often better to use language which does not require specialized knowledge, so that the reader will be able to make sense of it without a thesaurus.

According to the concept Domain-Driven Design, we should be using names from the domain itself in the program. So what could be the proper name here?

Well, EPD is short for Extended Position Description, which is a notation for representing a particular board state. SAN is short for Standard Algebraic Notation, which is used to encode a particular move.

So an EPD SAN is a particular board position when a particular move is applied to it. I propose to call the combination a "play" which is the act of moving from a particular board position. The code would then be:

  let difficulty_by_play = //...;
  let existing_plays = //...;
  let unique_moves_by_play = //...;
  fn play_to_condition((epd, san_plus): &Play) -> _ //...;

Cleaner code, I would claim.

https://en.wikipedia.org/wiki/Domain-driven_design https://en.wikipedia.org/wiki/Extended_Position_Description http://www.saremba.de/chessgml/standards/pgn/pgn-complete.ht...

Otherwise, please prioritize readability.

PosMove, but nothing wrong with MoveFromPosition either.

I also easily get annoyed by mouthful typing, so I usually do the following: write code in short identifiers and then rename them after I finish.

I wish dev envs could store two representations for an identifier, one short and one long, so one could easily switch between these (and also local/personal ones, or name comments at least). But that’s rocket science for text-based sources.

Perhaps, but a meaningful name is better than an arbitrary made-up name.

Thank you Tim! You did us a solid.

Over the years I’ve learnt to prioritise readability and to never abbreviate. Tab completion makes it a non-issue.

  ⴵ ⵛ ꘜ ⵣ ꕤ ꖜ 
  ꘖ ꧮ ⴲ Ⰴ Ⰺ

Obviously, if it needs a name or would greatly benefit from a name, give it a name. But have it at least somewhat descriptive. EPDSan, Sanepd, ESpair or some other variation is a lot better then "the first thing that comes to mind".

I'm not sure if you are familiar with where grep came from, but in short it is an abbreviation of a command in the original UNIX text editor: g/re/p - g for global command, re standing for your search query and p for print to screen or teletype. In that way, it is nothing more than an anachronism that would have been immediately obvious to anyone working in a UNIX environment at the time.

AWK and Perl are just programming languages. I think they have made up names because programming languages are singular entities, but have too many characteristics to condense into a short name. That's different from a function, which in conventional style does exactly one thing with only one or two characteristics and so can have a 'short' and descriptive name a few words long.

I don't disagree with your argument, but I wanted to point out that the examples you gave were made-up names out of tradition or necessity, not because they were intentionally designed to be memorable.

Using a real world name can actually be distracting because it may suggest attributes and behaviors which are not true of the thing.

This is why math papers use Greek letters. There is no words for “the amount of space where if the function is close enough than the cube of that function value will be within the initial tolerance requiring” so they just use “delta” and you learn the exact meaning of delta from its definition and usage.

I think this advice about “readable code” comes from every day business problems where there is a close correspondence between code processes and business processes.

Complex programs require expertise to understand, and only hubris would make you think longer names would substitute for studying the subject. Even “string” is technical jargon.