I really don’t like this idea if you are sharing this code base with anyone else.<p>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.<p>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.<p>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.
… a company I once worked at named everything after characters from a certain TV show. Effectively the same as a made up name. Let's just say one of the character's name was … a tough one to pronounce. And it caused endless "what's a … Kep?" type questions.<p>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.<p>You could have named it a "PoMo" (portmanteau of position-move), if you're tired of typing.<p>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?
If it occurs often enough, yes!<p>The human brain finds unexpected or weird words a lot more memorable than expected words.<p>grep is better than find "find-regular-expression"<p>awk is better than "execute-command-on-regular-expression"<p>perl has nothing to do with pearls<p>If it's a common command, concept, function, etc. that appears in may places, give it an odd name!<p>Document it thoroughly!<p>And don't go overboard. When everything is special, nothing is, with the added disadvantage that nothing is "readable" either.
This is good if you're good at coming up with names that are good, even if they're inscrutable.
If you're not so good at it, or do too much of it, then you end up getting a situation like the Urbit ecosystem.
This didn't sit quite right with me and I think I've pinned down why.<p>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.<p>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.<p>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?<p>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.<p>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:<p><pre><code> let difficulty_by_play = //...;
let existing_plays = //...;
let unique_moves_by_play = //...;
fn play_to_condition((epd, san_plus): &Play) -> _ //...;
</code></pre>
The result is legible, the concept is meaningful, and a naive reader could make sense of the variables and operations. No cognitive / conceptual overhead.<p>Cleaner code, I would claim.<p><a href="https://en.wikipedia.org/wiki/Domain-driven_design" rel="nofollow">https://en.wikipedia.org/wiki/Domain-driven_design</a>
<a href="https://en.wikipedia.org/wiki/Extended_Position_Description" rel="nofollow">https://en.wikipedia.org/wiki/Extended_Position_Description</a>
<a href="http://www.saremba.de/chessgml/standards/pgn/pgn-complete.htm#c8.2.3" rel="nofollow">http://www.saremba.de/chessgml/standards/pgn/pgn-complete.ht...</a>
Cuts both ways - often it's useful to do the opposite and inline the type to avoid declarations that make you jump around. Especially in the case of small, one-off, tuple-like structures. But I'd keep the Kep.
This works great if you're absolutely certain no other poor sap is going to have to work with your code. I do this myself for personal scripts!<p>Otherwise, please prioritize readability.
<i>wasn’t a mouthful like MoveFromPosition</i><p>PosMove, but nothing wrong with MoveFromPosition either.<p>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.<p>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.
I like this and seeing Kep reminds me of kip, a currency, and that got me thinking that currency names is a fun source of "made-up" names for things.
I once worked for a company that decided to eliminate internal codenames and instead use the actual brand names used by our customers. It removed a barrier to communication with no undesirable side effects.<p>Thank you Tim! You did us a solid.
This is awful. The alternative isn't "no name", it's a full and unambiguous name (even if it's a mouthful). If you can't come up with a good short name, stick with the long one.
I’ve been on teams that did generic names, and inevitably you end up with names like “work manager service” - whose work? Then it becomes an acronym, like WPS, and everyone ignores it anyways :)
Not my preference, even for personal projects. How many times have you come back to an old project and thought “what the heck is this?”. I know it’s a lot for me.<p>Over the years I’ve learnt to prioritise readability and to never abbreviate. Tab completion makes it a non-issue.
Instead of "kep", if you want something that visually stands out, there are also lots of fun little symbol-like characters you can use, even when you're dealing with a language where identifiers are limited to ID_Start/ID_Continue (e.g. Javascript, Rust). My favorite collection :)<p><pre><code> ⴵ ⵛ ꘜ ⵣ ꕤ ꖜ
ꘖ ꧮ ⴲ Ⰴ Ⰺ</code></pre>
Disagree, especially using that first name pops into your mind.<p>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".