Talk to any Python programmer and

eventually you will hear a funny combination of sounds.

PEP 8.

What the heck is a PEP?

PEP is actually an acronym that stands for Python Enhancement Proposal.

Python being an open source language lets anyone who

cares passionately about something, to submit a PEP.

There are hundreds of PEPs, that users have added over the years, and

they usually contain a single idea for an improvement to Python.

There are two very important PEPs that I think all Python programmers should learn.

PEPs 8 and 20.

Let's look at them.

PEP 8 is the PEP that defines how Python code should look.

Here in the second section,

it says, a foolish consistency is the hobgoblin of little minds.

So basically it's just saying that you should apply the rules in PEP 8 when and

where they make sense and do them as consistently as possible.

However, if, for

example, your company says that lines can be 100 characters long.

Don't worry about the PEP 8 rule that says lines should only be 79 characters.

There's a lot in PEP 8.

From how to use spaces both inside and outside of parenthesis.

To how to name variables and more.

So, don't try and memorize it all at once or live by every single rule.

It'll just drive you nuts.

But when you're writing Python, if you wonder if there's a preferred way to

format your code for something, take a look at PEP 8.

I've actually created a small Python script that violates a lot of

the rules of PEP 8.

Let's look at it together and try to fix the errors.

So here's the file.

Badpep8.py.

[BLANK_AUDIO]

Let's actually increase the font size just a little bit so we can see this better.

So, even though this file has many, many bad practices.

it will still run.

So you can see it has this a long string and it prints out 2.

And we get a bunch of errors here though when we run it.

So that's fine, that's actually because we have this import PEP 8.

PEP 8 checker.

So let's take those lines out.

Save that and let's just print again.

And there we go.

We've got some output.

So if this file is so bad why does it still run?

Well it's because we didn't write any invalid code in here.

We just wrote some kind of messy problems.

But let's see if we can fix those problems.

Get up here to the top of the file.

All right.

So let's start with the easy ones, which is spacing around functions.

So since these two functions here are what we call top level functions.

They're not inside of a class or inside of another function or anything like that.

There should be two blank lines between them.

All right.

So we've got that.

Also, our indenting down here should be four and not two.

So that'll be, that'll be better.

So we should also have a blank line between the methods in a class so

you know so we have a class here, class tree house.

And these two methods are right up against each other.

So there should be a blank line in between those.

Now we don't have to have a blank line between the class declaration and

the first method.

We don't need that.

But we do want this.

The reason we have this spacing is so

that things like functions or methods whatever, kind of stand out a little bit.

It's easy to see where one starts and the next one stops and so on and so forth.

I've got that a little backwards, where one stops and the other one starts.

If you don't understand that as much when they're inside of a class as they

do when they are on the run.

So, we should also have two lines between classes and other items.

So, since this class is top level.

We're gonna go ahead and put it with two lines.

All right, so we already talked about increasing the indentation.

Four isn't required, but it's very common, and it's recommended in PEP 8.

You can set your preferences and workspaces right down here and

whatever editor or IDE that you use will have a setting for that as well.

You also want to make sure that it's spaces and not tabs.

Or tabs and not spaces, it's your choice but

be consistent, they should be the same all through the file.

So let's actually look through here and

fix the indentation because if we look up here, there's way too many, too many here.

We should just have one tab right here.

And if we look at this one, these are three spaces in instead of four.

So, let's fix that too.

All right.

Fix that and fix that.

Okay. What about the rest of this?

All right, well the rest of this isn't indentation inside of functions so

let's leave that alone for right now.

But while we're working on spaces there should actually be spaces after every

comma and around operators that are not inside of a function call.

These just make it to where the code is cleaner and more easily stamped, so

let's fix all that.

So commas get spaces.

Lots of spaces here.

Okay.

And then this operator is not inside of a function call.

So we want spaces around it.

So let's move on down here.

oh, we've got commas.

So we'll put some spaces.

And an operator.

And then, we don't want a space between a function name and the parenthesis.

So let's fix that.

And there shouldn't be a space inside of the parenthesis either.

Well, more commas.

And this, let's put this up there on that line for right now.

And, oh, all right there shouldn't be spaces here either.

Okay.

So, I think that's pretty good.

Okay.

So, let's see.

Is there anything else that we need to fix?

And there is.

There's actually quite a few more things.

So, now that our spacing is more

conventional though we should fix our imports.

So forget these imports.

And we are importing two whole libraries on one line.

And we are doing it on line 20.

So by convention, imports are always up at the top of the file.

So we wanna do all of our imports at the top of the file.

And remember, we wanna have two blank lines before our function.

But we don't wanna import two libraries on one line.

We wanna do that on two lines.

So let's go ahead and break that up.

Import sys and import random.

While we were down here, I also noticed that we've got this crazy spacing.

Let me take out some of these lines.

I've got this crazy spacing right here where we are lining up our equal signs.

Don't do that.

Just do one space.

Okay?

It's fine. It's fine.

It's fine.

I know you want them to line up.

Don't make them line up because the thing is,

what happens when you change that variable.

We need to go in and

change all of your spacing all over again, it's just kinda weird.

Let's look, we've got another funny thing right here.

We've got a bunch of arguments and we've got one argument down here.

So, what we actually want to do, we can do this two different ways.

So we can do it like this, multiple lines but this line.

These two bits need to line up or, that's what will be

easier to do, is we put all of our arguments

down on their own lines and that would include this one.

And then this closing parentheses can be at the end of the line or

it can be on the next line.

It's your choice.

So we'll do it like that.

That looks a lot nicer.

Usually, your arguments though are going to fit on one line.

But just in case they don't.

This also makes it easier to edit it later on.

If fooBar changes and

only needs, say, three arguments, you can just highlight the line and

delete it, and you don't have to worry about rearranging things or whatever.

Something else, though, is we're using single letter variable names.

As you'll see in a later part of this course when we

start talking about the Python debugger.

Single letter variable names can really, really come back to bite you.

So let's fix that.

Let's give them new names.

So, we'll call them say alpha, beta, charlie and delta.

There we go. Now we have much nicer variable names.

Oh, but we printed out A down here, so we'll need to print out alpha.

Okay.

So, there's one other problem though with fooBar.

Let's go up here and look at fooBar.

So fooBar is a function name.

Function names and variable names in Python, not class names, but

function names and variable names, are generally all lower case and

would have an underscore between words.

So, we'll call this foo_bar instead of fooBar.

[BLANK_AUDIO]

And that way it's nice and cleaned up.

So, speaking of classes though, our class has a lowercase t, and it shouldn't.

It should have a capital T.

And down here at the bottom.

We call Treehouse, so we need to capitalize that T, as well.

So the reason that we have two different rules for naming.

Why do we name functions differently than we name classes?

It's so that they stand out in their own way.

Classes always have this capitalization to them.

They're easy to spot and functions are lower cased with underscores,

which is commonly called snake case.

They're easy to spot as well.

So we've gone through and we've changed everything.

And looking at this file,

I don't see anything else that we have to change right away.

So, let's, we already saved it.

Let's come down here and let's try running it again.

We still get back the things that we we got originally.

So it must work just fine.

So we have this program called flake8.

Which we can actually run our script against.

And it gives us errors.

So we can see, here, that we have three errors.

So let's fix this.

So we come up here, we see that this is important but

unused, so let's just get rid of it.

We see that random is imported but unused so let's get rid of that.

And then we see that, I notice these have a one and a two.

Those are the line numbers.

So now we can see that on line 36, which would now be line 34,

cuz we deleted two things.

That we should have at least two spaces before an end line comment.

So let's come down here to line 34 I'm sorry 32

cuz I deleted some blank lines as well.

And we see there's just one space right here.

There should be at least two.

So let's save and let's actually run our flake8 again.

Nothing's wrong.

No problems at all.

Excellent.

Learning to write your code to PEP 8 standards really helps when

working with a team and once you know the rules,

makes it really easy to find syntax mistakes in your own code.

Python is sometimes like poetry.

The presence of the words on the page holds nearly as much weight as

the words themselves.

As we'll see in the next video,

Python values the beauty of your code pretty highly