Write Pythonic Code Like a Seasoned Developer Transcripts
Chapter: Style guidance from PEP 8
Lecture: Naming conventions
Login or
purchase this course
to watch this video and the rest of the course contents.
0:01
Let's talk about naming conventions. PEP 8 actually says a lot about how you should name
0:06
your functions, methods, classes, and other symbols in your code. Before we get to the specifics,
0:12
I just want to give you one of my core programming guidelines around naming, and that is: Names should be descriptive.
0:18
Let's imagine you are writing a function. If you write the function and then you start to put a comment at the top to describe what that function does,
0:25
I encourage you to stop and think about just making the concise statement about what that comment is the name of the function.
0:33
I am a big fan of Martin Fowler's reafctoring ideas and especially the "code smells" that he talks about,
0:39
and "code smells" are things in code that are not really broken but they kind of smell off, like a function that is 200 lines long,
0:48
it's not broken, it just doesn't seem right. It sort of smells wrong, right, so breaking that
0:54
to a smaller bunch of functions through refactoring might be the solution. And when he talks about comments he says
1:00
comments are deodorant for code smell, instead of actually fixing the code so it's remarkably descriptive and easy to understand,
1:07
people often put comments to say "here is this really hard to understand thing, and here is the comment that says why it's this way
1:14
or what it actually does or maybe in my mind, what it really should be named." So my rule of thumb is if you need a comment
1:20
to describe what a function does, you probably need a better name. That said, let's talk about how PEP 8 works.
1:25
So here is some code that is PEP 8 compliant. We have a module called data_access and modules should all have short,
1:32
all lower case names and if needed for readability you can put underscore separating them. Next you see we have a content that does not change
1:42
during the execution of our code, it's called TRANSACTION_MODE and I forced it to be serializable. These should be all upper case.
1:49
Classes, classes have cap word names, like this, CustomerRepository, capital C capital R. Variables and function arguments are always lower case,
2:00
possibly separated with underscores as well; functions and methods lower case, again, possibly separated with underscores.
2:08
And if you happen to create your own exception type, here we might want to raise a RepositoryError and it derives from the exception class,
2:15
when you have exceptions they should always be named in error, so "SomethingError". Here we have RepositoryError.
2:23
As you have seen in other cases, PyCharm will help us here, notice I renamed other_method, here to be Javascripty style
2:29
with the capital M and not the underscore, you hover over it PyCharm will say "no, no, no, you are naming your functions wrong."
2:37
It'll even let us hit Alt+Enter and give us some options about fixing this up, it doesn't quite understand how to rename it for us
2:45
but at least it gives us the option to go over here and do a rename. Now this is not this renaming in place, but this is a refactor rename
2:50
across the entire project, so if we had hundreds of files, docstrings, that sort of stuff, this would fix all of those.
2:58
It'll show us where it's going to change, here we don't have anything going on really so it's just this one line. Now, our warning is gone.