Preview
Video Player
00:00
00:00
PEP 8
12:32PEP 8 is Python's style guide. It's a set of rules for how to format your Python code to maximize its readability. Writing code to a specification helps to make large code bases, with lots of writers, more uniform and predictable, too.
Talk to any Python programmer and
0:00
eventually you will hear a funny
combination of sounds.
0:02
PEP 8.
0:05
What the heck is a PEP?
0:06
PEP is actually an acronym that stands for
Python Enhancement Proposal.
0:08
Python being an open source language lets
anyone who
0:13
cares passionately about something, to
submit a PEP.
0:16
There are hundreds of PEPs, that users
have added over the years, and
0:19
they usually contain a single idea for an
improvement to Python.
0:23
There are two very important PEPs that I
think all Python programmers should learn.
0:27
PEPs 8 and 20.
0:31
Let's look at them.
0:33
PEP 8 is the PEP that defines how Python
code should look.
0:35
Here in the second section,
0:39
it says, a foolish consistency is the
hobgoblin of little minds.
0:40
So basically it's just saying that you
should apply the rules in PEP 8 when and
0:46
where they make sense and do them as
consistently as possible.
0:50
However, if, for
0:53
example, your company says that lines can
be 100 characters long.
0:54
Don't worry about the PEP 8 rule that says
lines should only be 79 characters.
0:58
There's a lot in PEP 8.
1:03
From how to use spaces both inside and
outside of parenthesis.
1:05
To how to name variables and more.
1:08
So, don't try and memorize it all at once
or live by every single rule.
1:10
It'll just drive you nuts.
1:16
But when you're writing Python, if you
wonder if there's a preferred way to
1:17
format your code for something, take a
look at PEP 8.
1:21
I've actually created a small Python
script that violates a lot of
1:24
the rules of PEP 8.
1:28
Let's look at it together and try to fix
the errors.
1:29
So here's the file.
1:34
Badpep8.py.
1:36
[BLANK_AUDIO]
1:38
Let's actually increase the font size just
a little bit so we can see this better.
1:43
So, even though this file has many, many
bad practices.
1:47
it will still run.
1:51
So you can see it has this a long string
and it prints out 2.
1:58
And we get a bunch of errors here though
when we run it.
2:03
So that's fine, that's actually because we
have this import PEP 8.
2:09
PEP 8 checker.
2:12
So let's take those lines out.
2:15
Save that and let's just print again.
2:19
And there we go.
2:23
We've got some output.
2:24
So if this file is so bad why does it
still run?
2:28
Well it's because we didn't write any
invalid code in here.
2:30
We just wrote some kind of messy problems.
2:33
But let's see if we can fix those
problems.
2:36
Get up here to the top of the file.
2:39
All right.
2:41
So let's start with the easy ones, which
is spacing around functions.
2:42
So since these two functions here are what
we call top level functions.
2:46
They're not inside of a class or inside of
another function or anything like that.
2:51
There should be two blank lines between
them.
2:55
All right.
3:02
So we've got that.
3:03
Also, our indenting down here should be
four and not two.
3:05
So that'll be, that'll be better.
3:11
So we should also have a blank line
between the methods in a class so
3:13
you notice we have a class here, class
treehouse.
3:16
And these two methods are right up against
each other.
3:19
So there should be a blank line in between
those.
3:22
Now we don't have to have a blank line
between the class declaration and
3:25
the first method.
3:30
We don't need that.
3:31
But we do want this.
3:33
The reason we have this spacing is so
3:35
that things like functions or methods
whatever, kind of stand out a little bit.
3:37
It's easy to see where one starts and the
next one stops and so on and so forth.
3:41
I've got that a little backwards, where
one stops and the other one starts.
3:46
But they don't have to stand out as much
when they're inside of a class as they
3:50
do when they are on their own.
3:53
So, we should also have two lines between
classes and other items.
3:56
So, since this class is top level.
4:02
We're gonna go ahead and put it with two
lines.
4:05
All right, so we already talked about
increasing the indentation.
4:11
Four isn't required, but it's very common,
and it's recommended in PEP 8.
4:14
You can set your preferences and
workspaces right down here and
4:19
whatever editor or IDE that you use will
have a setting for that as well.
4:22
You also want to make sure that it's
spaces and not tabs.
4:26
Or tabs and not spaces, it's your choice
but
4:30
be consistent, they should be the same all
through the file.
4:33
So let's actually look through here and
4:36
fix the indentation because if we look up
here, there's way too many, too many here.
4:38
We should just have one tab right here.
4:44
And if we look at this one, these are
three spaces in instead of four.
4:47
So, let's fix that too.
4:54
All right.
4:56
Fix that and fix that.
4:58
Okay.
What about the rest of this?
5:04
All right, well the rest of this isn't
indentation inside of functions so
5:07
let's leave that alone for right now.
5:11
But while we're working on spaces there
should actually be spaces after every
5:14
comma and around operators that are not
inside of a function call.
5:19
These just make it to where the code is
cleaner and more easily stamped, so
5:24
let's fix all that.
5:28
So commas get spaces.
5:29
Lots of spaces here.
5:35
Okay.
5:36
And then this operator is not inside of a
function call.
5:37
So we want spaces around it.
5:40
So let's move on down here.
5:44
oh, we've got commas.
5:47
So we'll put some spaces.
5:49
And an operator.
5:52
And then, we don't want a space between a
function name and the parenthesis.
5:55
So let's fix that.
6:01
And there shouldn't be a space inside of
the parenthesis either.
6:02
Well, more commas.
6:06
And this, let's put this up there on that
line for right now.
6:10
And, oh, all right there shouldn't be
spaces here either.
6:15
Okay.
6:19
So, I think that's pretty good.
6:20
Okay.
6:24
So, let's see.
6:25
Is there anything else that we need to
fix?
6:26
And there is.
6:28
There's actually quite a few more things.
6:29
So, now that our spacing is more
6:31
conventional though we should fix our
imports.
6:34
So forget these imports.
6:38
And we are importing two whole libraries
on one line.
6:39
And we are doing it on line 20.
6:44
So by convention, imports are always up at
the top of the file.
6:46
So we wanna do all of our imports at the
top of the file.
6:52
And remember, we wanna have two blank
lines before our function.
6:54
But we don't wanna import two libraries on
one line.
6:59
We wanna do that on two lines.
7:03
So let's go ahead and break that up.
7:06
Import sys and import random.
7:09
While we were down here, I also noticed
that we've got this crazy spacing.
7:11
Let me take out some of these lines.
7:18
I've got this crazy spacing right here
where we are lining up our equal signs.
7:21
Don't do that.
7:26
Just do one space.
7:27
Okay?
7:30
It's fine.
It's fine.
7:30
It's fine.
7:33
I know you want them to line up.
7:34
Don't make them line up because the thing
is,
7:36
what happens when you change that
variable.
7:38
We need to go in and
7:40
change all of your spacing all over again,
it's just kinda weird.
7:41
Let's look, we've got another funny thing
right here.
7:45
We've got a bunch of arguments and we've
got one argument down here.
7:47
So, what we actually want to do, we can do
this two different ways.
7:50
So we can do it like this, multiple lines
but this line.
7:56
These two bits need to line up or,
what's probably
8:01
easier to do, is we put all of our
arguments
8:06
down on their own lines and that would
include this one.
8:12
And then this closing parentheses can be
at the end of the line or
8:18
it can be on the next line.
8:21
It's your choice.
8:22
So we'll do it like that.
8:24
That looks a lot nicer.
8:25
Usually, your arguments though are going
to fit on one line.
8:28
But just in case they don't.
8:31
This also makes it easier to edit it later
on.
8:32
If fooBar changes and
8:34
only needs, say, three arguments, you can
just highlight the line and
8:36
delete it, and you don't have to worry
about rearranging things or whatever.
8:39
Something else, though, is we're using
single letter variable names.
8:44
As you'll see in a later part of this
course when we
8:49
start talking about the Python debugger.
8:53
Single letter variable names can really,
really come back to bite you.
8:56
So let's fix that.
9:00
Let's give them new names.
9:03
So, we'll call them say alpha, beta,
charlie and delta.
9:04
There we go.
Now we have much nicer variable names.
9:16
Oh, but we printed out A down here, so
we'll need to print out alpha.
9:18
Okay.
9:24
So, there's one other problem though with
fooBar.
9:26
Let's go up here and look at fooBar.
9:30
So fooBar is a function name.
9:33
Function names and variable names in
Python, not class names, but
9:35
function names and variable names, are
generally all lower case and
9:39
would have an underscore between words.
9:44
So, we'll call this foo_bar instead of
fooBar.
9:46
[BLANK_AUDIO]
9:51
And that way it's nice and cleaned up.
9:55
So, speaking of classes though, our class
has a lowercase t, and it shouldn't.
9:59
It should have a capital T.
10:05
And down here at the bottom.
10:08
We call Treehouse, so we need to
capitalize that T, as well.
10:12
So the reason that we have two different
rules for naming.
10:19
Why do we name functions differently than
we name classes?
10:22
It's so that they stand out in their own
way.
10:26
Classes always have this capitalization to
them.
10:28
They're easy to spot and functions are
lower cased with underscores,
10:31
which is commonly called snake case.
10:37
They're easy to spot as well.
10:40
So we've gone through and we've changed
everything.
10:42
And looking at this file,
10:45
I don't see anything else that we have to
change right away.
10:47
So, let's, we already saved it.
10:53
Let's come down here and let's try running
it again.
10:56
We still get back the things that we we
got originally.
11:01
So it must work just fine.
11:04
So we have this program called flake8.
11:09
Which we can actually run our script
against.
11:13
And it gives us errors.
11:17
So we can see, here, that we have three
errors.
11:22
So let's fix this.
11:25
So we come up here, we see that this is
important but
11:27
unused, so let's just get rid of it.
11:30
We see that random is imported but unused
so let's get rid of that.
11:32
And then we see that, I notice these have
a one and a two.
11:36
Those are the line numbers.
11:42
So now we can see that on line 36, which
would now be line 34,
11:44
cuz we deleted two things.
11:47
That we should have at least two spaces
before an end line comment.
11:48
So let's come down here to line 34 I'm
sorry 32
11:52
cuz I deleted some blank lines as well.
11:58
And we see there's just one space right
here.
11:59
There should be at least two.
12:02
So let's save and let's actually run our
flake8 again.
12:04
Nothing's wrong.
12:09
No problems at all.
12:10
Excellent.
12:12
Learning to write your code to PEP 8
standards really helps when
12:12
working with a team and once you know the
rules,
12:15
makes it really easy to find syntax
mistakes in your own code.
12:18
Python is sometimes like poetry.
12:22
The presence of the words on the page
holds nearly as much weight as
12:24
the words themselves.
12:27
As we'll see in the next video,
12:28
Python values the beauty of your code
pretty highly
12:29