PEP8

Today, we'll do a brief overview of PyCharm

and the PEP8 style guide. Style guides are

important because they help you to provice

clean, consistent and easy to read code. If

you're working in a team and someone is

reading code written by different team

members, you want them to be able to

focus on the content of the code, rather

than differences in formatting. And if you

move from one company to another,

you can count on having to learn a new

style guide. For Python, the default style

guide is called PEP 8. You can find PEP 8

online. The easiest thing to do is search

for PEP 8. It should be the first result,

and you should familiarize yourself

to the standard. While we will be strictly

adhering to PEP 8 in this class, I want to

draw your attention to this section called

"A Foolish Consistency is the Hobgoblin

of Little Minds" and basically it says you

should use PEP 8 most of the time, but if

PEP 8 is getting in the way of the

readability of the code, then you have

permission to deviate. For me, this

happens a lot of times when I have long

lines that I need to break up. If I follow

the PEP 8 too strictly, I end up with

code that's unreadable. Now I've written

some code here in PyCharm that's just

full of PEP 8 violations and some warnings

as well. PyCharm is nice because it alerts

you to your PEP 8 violations real time as

you code. It does that in the source code

window on the right hand side using

these dashes. And if we hover over the

dashes, we can see the specific violations.

This one says "PEP 8: expected 2 blank

lines, found one". I can click on that dash

and it brings me to the right violation.

If I hover over the line of code, I

see the violation again. "PEP 8: expected

2 blank lines, found 1" and what that means

is there should always be 2 blank lines

before a class definition. So I'm

going to enter another blank line,

and my violation goes away. Now we'll

continue down fixing this code so you

can see some of the more common violations.

Usually we want spaces around operators

like equals signs. One exception is with

default values to parameters. Here, we

have a parameter "journey_length" that

has a default value of 7. In this case, I

want to take out the spaces around the

equals sign. Of course in the next line,

we have the opposite problem. It says

"PEP 8: missing white space around operator"

and that's because this is not a default

value. This is an assignment inside the

method, so we want to add the white

space around the equals sign. The we

have a comment here, on European Swallow,

and inline comments need a space after the

hashtag to make them easier to read. They

also need 2 spaces before the hashtag.

You can see as we go along, the errors

are disappearing.

Inside a class, we should have one blank

line in between each method.

So we have to add a blank line before

this method "get_velocity".

The next issue is actually not a PEP 8

value, it's a warning, and you can see

the difference because it doesn't say

PEP8. The PEP8 violations are prepended

with PEP8. The warning is that we created

a new instance variable "velocity_gotten"

inside this method. Generally, instance

variables are used in several places inside

our code, so we'd like to initialize them

inside the unit method.

So what we'll do is we'll just add

"self.velocirt_gotten = " and we could

choose a default value. Probably

"false makes sense in this context,

or you might choose "none".

Push enter, and then that warning goes away.

Whenever we're comparing an object

to a built in type like None type,

we don't use equal to (=) or not equal to (!=),

we use "is" or "is not". So we're going to

replace (!=) with "is not". If you've been

coding in other languages, you might be

in the habit of adding semicolons to the

end of each each line. Python will accept

that, but it's not the standard, so we

want to get rid of that semicolon.

Again, we need a space between each

method. We almost always want a

single space after every comma,

and then after the end of the last line,

we should have a blank line.

Sometimes it will automatically indent, so

we'll just backspace, and let's go back and

see what's left. This is an interesting comment.

It says "method 'convert_to_mph' may be 'static'".

So, PyCharm noticed that we haven't

actually used any instance variables

inside this method, and it's letting

us know that we probably should be

coding this as a static method.

So we'll add the decorator, "@staticmethod"

static methods don't take a self parameter

and that warning is cleared.

Just two more issues here. First, we have

our class definition with parenthases.

Since we're not specifying any

class to inherit from, we can get rid of

the parentheses. And the final note

is that we haven't used our paramater

journey length anywhere in our code,

so we should either remove journey length

as a parameter, or perhaps, add an

assignment inside in it.

And now our code is clean, and we get

a satisfying little green check mark

up at the top.