how to name things

• the name should not be identical to the implementation (e.g. AssignContent over CreateAssignment). If you name functions after what they do, as soon as they do something different the name becomes misleading.
• Remain consistent with the idioms of human language: e.g. in English prefer “on” with dates and “at” with times
• name your variables in conversational English: add_description_to_course. Abbreviations cost more in confusion than they save in memory (and in compiled languages that doesn’t matter anyway)
• avoid meaningless placeholder names like “foo”.
• avoid incorrect names, such as calling a shipment a consignment, or a function “save” that does not actually save something.
• Avoid inconsistent names, such as calling the same thing 2 different names in 2 places.
• Avoid vague verbs like “get” and “do”—they may be true, but more specific verbs like “fetch”, “calculate”, and “derive” better convey intention. Likewise with vague nouns such as “manager”: opt for more specific terms like “builder” or “calculator”.
• Single-letter names are generally bad unless extremely conventional (such as “i” for an iterative index). Even then, they force an additional step between reading and understanding.
• Avoid incidental names, especially based on UI, e.g. naming a database table “library_contents” because its contents appeared on a page called “Library”…until that page got renamed
• Too-literal names like “appointment list”, prefer domain terminology like “calendar”. Likewise, “employee” is a better name than “company person”.

For Libraries

• I used to like naming client modules after services (e.g. naming Lessonly’s ruby API client Lessonly) but after being in the consuming end end of that, learned that it prevents callers from implementing their own interface. For example, a consumer might want a top-level Github namespace that abstracts over individual calls to the Github API, which they couldn’t do if Github’s Ruby client were named Github. As it’s called Octokit, that possibility remains open. If as a library author you aren’t as clever, you might just append “client”, e.g. GithubClient since that’s literally what it is.