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 know so we have a class here, class tree house. 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 If you don't understand that as much when they're inside of a class as they 3:50 do when they are on the run. 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, that's what will be 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