While Python may be the name of both a programming language and a snake, snake case is an unrelated concept stemming from the way we name things in programming. In the rest of this article, we’ll take a look at what snake case is, when you would use it, and even why you should use it. Let’s dig in!
Table of Contents
- Concept Overview
- When to Use Snake Case in Python?
- Why Follow Snake Case in Python?
- What Naming Conventions Do Other Languages Use?
- Learning About Conventions
Concept Overview
By far, snake case has to be one of the lowest hanging fruit concepts I’ve ever written about, but we’ll see just how hard of a concept it is to cover.
To start, snake case, which is sometimes written as snake_case as should be obvious shortly, describes lowercase phrases where the spaces between words are replaced by underscores. For example, the phrase “red apple” would be written as red_apple in snake case.
In the context of Python, snake case is used for naming things, like functions and variables. Therefore, snake case is what’s known as a naming convention. In general, there are many naming conventions that vary from language to language and even from team to team. But, I would argue that snake case is fairly universal in the Python community. I usually find it a bit odd when it’s not being followed.
Alternatives to snake_case include camelCase, kebab-case, and flatcase, some of which you may even see used in Python for special cases.
Naturally, I’m sure this short introduction left you will some questions, so let’s get to them!
When to Use Snake Case in Python?
When writing code in Python, you will have plenty of opportunities to name things. For example, whenever you create a variable, you will have to give it a name. The same goes for functions, parameters, modules, classes, and constants. But, not all of them should make use of snake case.
Explicitly, snake case is used when naming variables, functions, parameters, and modules—as in my_variable, my_function, my_parameter, and my_module, respectively. In contrast, upper camel case is used when naming classes, as in MyClass, and upper case is used with constants, as in MY_CONSTANT. Here’s that same information in a table:
| Python Context | Casing |
|---|---|
| Functions, Variables, Parameters, and Modules | snake_case |
| Classes | UpperCamelCase |
| Constants | UPPER_CASE |
Generally, I would not expect to see camel case, kebab case, or flat case anywhere in Python code, but I’m sure people do it. Seeing camel case is usually a way of detecting a Java programmer, as I used to be one myself.
Also, I should mention, as rzuckerm has pointed out in the Discord
, that several of the Python core libraries disobey this convention, such as logging and threading. Fortunately, the Python developers are aware of this and have carved out an exception for camelCase (or mixedCase as they call it) in PEP8.
Why Follow Snake Case in Python?
The question of why you should follow snake case or any rules, really, is more of a philosophical debate than a practical one, but I’ll entertain it.
One possible argument would be one of efficiency. Typically, developers want to eliminate as much cognitive overhead as possible when reading code, and naming conventions are one of our ways of doing that. If you can quickly tell what a name means by glancing at it, you don’t have to bother hunting down its origins.
Another possible argument would be one of polish. As a craft, software development deserves as much care as any other craft. For example, how many of those videos have you seen of rushed construction jobs where tools and junk are left hidden in the walls of a house? Now imagine your users seeing your source code that does not subscribe to any rules.
Perhaps another argument could be around teamwork. Generally, this argument ties into efficiency, but it’s normal to want to use a shared language when you communicate with your team. Believe it or not, code is a form of communication and using the right language (e.g., snake_case in python) shows that you’re a part of the ingroup (i.e., a real software developer).
Lastly, one argument could be around selfishness. When I teach folks how to code, it can be hard to get students to subscribe to conventions, especially if they have previous coding experience. My trick to get folks to care about rules is to center them in the conversation. Forget some hypothetical team. You’re the one who is going to be reading that code again later, so why not do your future self a favor?
What Naming Conventions Do Other Languages Use?
While this is a wonderful question, I cannot even begin to answer it. Not all languages have a strong community around them or have similar philosophical leanings that would cause the community to adopt certain conventions.
That said, there are a few conventions I know off the top of my head. As I said previously, Java is somewhat famous for following the camel case convention for everything but classes, which follow upper camel case, and constants, which follow upper case.
In a similar vein, C# follows a lot of the same conventions as Java, as they are very similar languages. Though, I’m sure there are minor differences, like the way the C# community prefers to place their braces. Likewise, I would suspect that Kotlin also follows the same conventions.
It’s been some time since I’ve used many C-style languages, such as C, C++, and even JavaScript, so I don’t recall the naming conventions in those spaces. That said, I consider those languages and their communities to be a bit of the wild west, so I would imagine there aren’t many universal conventions.
Beyond that, I will say that the Sample Programs repo, which contains code snippets in a bunch of programming languages, has a spot to declare the casing of at least the file names for every programming language in the repo. So, you might take a peek there!
Learning About Conventions
Generally, programming languages, like Python, are going to have community-driven conventions. These conventions can be subscribed to in whole or in part depending on the context. As a result, you may find that some of your personal conventions are banned in certain teams, and that’s okay! Every group is going to have their reasons for why they prefer certain conventions over others. These cause arguments every day in our communities, so I don’t expect them to stop anytime soon.
As a matter of fact, I’ve been involved in a few of those debates myself, which you can read about below:
- No One Uses Loop Invariants: Just Ask Google
- What Makes Multiple Return Statements Bad Practice?
- There Is No Value in Ranking Programming Languages: The Cost of Gatekeeping in Tech
With that said, know that many of the strong opinions you’ll hear from people in tech are just that, opinions. As far as I know, the conventions we hold dear have rarely been researched, if ever, so there’s little to no empirical evidence driving these debates. Though, it looks like there may be some research coming down the pipeline, which is exciting!
Also, while you’re hear, why not browse some of the following resources (#ad):
- Effective Python: 90 Specific Ways to Write Better Python
- Python Tricks: A Buffet of Awesome Python Features
- Python Programming: An Introduction to Computer Science
Likewise, you’re welcome to take your support a step further by checking out my list of ways to grow the site. Otherwise, take care, and hopefully I’ll see you again soon!
Recent Code Posts
Unpacking the Jargon Around Compilers, Interpreters, and More
Today, we're going to get a little pedantic and try to define concepts like compiler and interpreter. Of course, I ultimately don't think it matters what the exact definitions are for practical...
Generally, people think of Python as a messy language because it lacks explicit typing and static type checking. But, that's not quite true in modern times. Surely, we can take advantage of type...