A made-up name is better than no name
mbuffett.com
A made-up name is better than no name
1–10 of 86 posts
Re: A made-up name is better than no name
#2This 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!
Otherwise, please prioritize readability.
Re: A made-up name is better than no name
#3This 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! Otherwise, please prioritize readability.
Documentation is probably better than readability because readability makes a lot of assumptions arising from being close to the code...for example, Swedish names are not gonna be all that readable for most programmers (this holds true for English names as well).
Re: A made-up name is better than no name
#4A made-up name is fine if (A) your code is private and (B) fixing it later is easy.
Re: A made-up name is better than no name
#5This 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! Otherwise, please prioritize readability.
It’s one made-up name in a 30,000 line codebase. I think if anyone else ever works with the project they’ll have a lot harder things to catch up on than this convention
Re: A made-up name is better than no name
#6This 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.
Re: A made-up name is better than no name
#7Cuts 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.
Re: A made-up name is better than no name
#8I really don’t like this idea if you are sharing this code base with anyone else.
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.
Re: A made-up name is better than no name
#9If it occurs often enough, yes!
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.
Re: A made-up name is better than no name
#10I often remove the vowels, so I'd have probably gone with 'pdSn' as the shorthand for it.