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.

Talk Python's Mastodon Michael Kennedy's Mastodon