Naming Things

“There are only two hard things in Computer Science: cache invalidation and naming things”

Phil Karlton

When writing software, we often find ourselves needing to name things: files, classes, variables, GitHub repositories, Python packages, etc.  As noted above, doing this well is hard; a programmer can easily pick a name that solves the immediate problem, but many such well-intended choices can be confusing or misleading to other people coming from different contexts (or after some time has passed, even to the programmer who named it).  A comprehensive set of guidelines on how to name things well could fill an entire book, but here are some guidelines that are likely to be useful to developers at edX.

• Python Naming Conventions - As stated in the edX Python Style Guide, we follow PEP 8 in this context
• JavaScript Naming Conventions - As stated in the edX JavaScript Style Guide, we follow the Airbnb JavaScript Style Guide in this context
• IT's Best Practices for Naming - This has some good general guidelines, and some specific considerations for JIRA artifacts and such.
• Package Names - If the project is edX specific, use the "edx-" prefix. Don't use it if it the scope is more general (for example tools like "bok-choy", "diff-cover", etc.)  Earlier discussion of this topic: Standards for Engineering, Coding, Repository
• Repository Names - The name of our GitHub organization is "edx", so it's redundant to add "edx-" to the package name as well.  It's OK if this means that a repository without "edx-" in its name produces a Python package which does have it.