Like all programmers, I am forever terrible at naming things but also abhor long names. For projects and other top level organization like folders, I default to picking the most obvious possible single word name.
For example, all the ebooks I've downloaded go in a folder named books. By the same logic, the folder in my scripts repository for working with books should also be named books. The folder of things which should be synced has a folder called books. And if I ever were to write a book, it'd go in a folder called books.
That will work, there's no direct conflicts. But if I want to search for things or navigate quickly, it'd be better if they all had unique names. Life is easier with less ambiguity.
I could add a suffix e.g. books, book-scripts, books-sync, book-projects, but following the rule of obvious names in practice the folder structure would be books, scripts/book-scripts, sync/books-sync, projects/book-projects. Now the names are redundant and clunky.
I could come up with unique names e.g. books, librarian, shelf, drafts, but that requires naming things and quickly becomes ambiguous.1 What if I have other writing later that I don't want to put with books?
My solution is to translate into other languages and use the romanization. The list of languages is longer than I'll ever practically need, and they can be used as sets by language. In practice I basically never need more than three or four names, so I stick to the same few languages I happen to find memorable.
For things which don't have good translations, I make up my own convention by appending a suffix. I find pronounceability helps with memorability, but your mileage may vary. The point is to have a way of getting arbitrarily many easy to remember single word names which provide consistent meanings and come in sets.
Any system will do, as long as you remember it.
- Rew
Nightly Notes
Writing this motivated me to go rename a bunch of things for consistency which I've been procrastinating on. I'll have to relearn the new names, but it's worth it in the long run to stop mixing things up.
Not the first time writing about something has motivated me to do it a bit better. I try to be clear about when I use something as a guideline rather than a strict rule, but it's forever going to be true that the written description of what I'm doing and why is going to make it sound more consistent than it actually is.
Do as I say, but it's also probably fine if you do as I do. I'll get there eventually, and nothings going to blow up in the meantime.
- Rew
-
The process of coming up with this example list already took longer than it should have. ↩