CS50 Video Player
    • 🧁

    • 🍧

    • 🍓

    • 🍿
    • 0:00:00[MUSIC PLAYING]
    • 0:00:23DAVID MALAN: All right, this is CS50's introduction
    • 0:00:26to programming with Python.
    • 0:00:28My name is David Malan, and this is our look at style.
    • 0:00:31Now, up until now, we've been writing code that's hopefully at least correct.
    • 0:00:35That is, the code does what you intended to do.
    • 0:00:37And hopefully, it's also well designed, that
    • 0:00:40is, you're using relatively few lines of code
    • 0:00:43to achieve some goal while still ensuring that it's readable.
    • 0:00:46You're perhaps using functions that save you the trouble of reinventing wheels,
    • 0:00:50so to speak.
    • 0:00:51But it's possible that your code isn't necessarily manifesting the best style
    • 0:00:55as well, which is another form of quality
    • 0:00:58that you can ascribe to some code.
    • 0:00:59Now style, or the right type of style to use, is rather subjective,
    • 0:01:03and it depends typically on the programmer, on the company,
    • 0:01:06on the course, or on the language that you're actually using.
    • 0:01:09But within the Python community, it turns out
    • 0:01:11that there's some pretty regimented standards
    • 0:01:13that most all python Programmers adhere to,
    • 0:01:16or rather, are expected to adhere to, because this particular language
    • 0:01:20and community has tried to codify some of their preferences
    • 0:01:23for how your code should look in the form of something called PEP 8.
    • 0:01:28So a PEP or P-E-P--
    • 0:01:29Python enhancement proposal-- is a set of proposals
    • 0:01:32that the community within the world of Python
    • 0:01:34typically generate to not only propose new ideas, but also to codify,
    • 0:01:38ultimately, certain standards.
    • 0:01:40And PEP 8 happens to be such a proposal that standardized, or rather tried
    • 0:01:45to standardize, what our code should look like-- that is to say,
    • 0:01:48it's quite possible to write code that's not only correct,
    • 0:01:51it might even be well designed, but it's just really a mess.
    • 0:01:54And it just doesn't look very good.
    • 0:01:56It's not very pretty.
    • 0:01:58It's therefore harder to read.
    • 0:01:59It's harder for others to read.
    • 0:02:01And therefore, it's just not as maintainable.
    • 0:02:03And any time you make something harder to read or less maintainable,
    • 0:02:06you're just increasing the probability, dare say down
    • 0:02:09the line, of introducing bugs.
    • 0:02:11So it's a good thing for your code to be properly formatted,
    • 0:02:14just like in the world of writing emails or essays or books or documents
    • 0:02:18or beyond.
    • 0:02:19It tends to be good practice to capitalize
    • 0:02:21certain words, at least in English, use good punctuation, use paragraph
    • 0:02:25breaks and the like.
    • 0:02:26So even if you're relatively new to programming, at least
    • 0:02:28in English or your own human language, odds
    • 0:02:30are you've had quite a bit of practice with writing language
    • 0:02:34in the human world that also just looks good as well.
    • 0:02:37Well, what does it mean to look good in the world of programming code?
    • 0:02:40Well, let me propose that if you look at PEP 8 itself,
    • 0:02:43which is available on the internet via this address here,
    • 0:02:46it turns out that it tries to standardize
    • 0:02:48a number of details that would be manifest in your own code
    • 0:02:52once you've written a number of lines.
    • 0:02:53And the overarching premise of PEP 8, and really
    • 0:02:56the notion of style in the Python community especially,
    • 0:02:59is that "readability counts."
    • 0:03:01And typically, languages-- Python among them--
    • 0:03:04come with what's generally known as a style guide.
    • 0:03:06A style guide, not unlike PEP 8, is some kind
    • 0:03:09of guide-- a document, either printed or perhaps internet
    • 0:03:12based-- that just tries to standardize what everyone's code should look like.
    • 0:03:16So a course that you're taking might have its own style guide.
    • 0:03:18A company you're working for might have its own style guide.
    • 0:03:21You, down the road as a professional programmer,
    • 0:03:24might have your own style guide for your own code.
    • 0:03:26But within the Python community, they've tried generally
    • 0:03:28to standardize for the most part a lot of these details.
    • 0:03:31And ultimately-- quote, unquote too--
    • 0:03:33a style guide is about consistency, consistency with this style guide,
    • 0:03:37in the context of Python is important.
    • 0:03:39Consistency within a project is more important.
    • 0:03:42And consistency within one module or function is the most important.
    • 0:03:46So that is to say, these aren't necessarily hard
    • 0:03:49and fast rules, but rather guidelines that
    • 0:03:51should guide the design of your own code.
    • 0:03:53Now, how do you go about designing, or how do you
    • 0:03:56go about styling your code well?
    • 0:03:58Well, it boils down to things like this and many more--
    • 0:04:01indentation, using consistent indentation.
    • 0:04:04Now, in some languages, it doesn't strictly
    • 0:04:06have to be there, when you indent one line of code under another,
    • 0:04:09or it could be one space, or two spaces, three spaces, or four-- maybe
    • 0:04:12even eight, or an actual tab.
    • 0:04:14In the world of Python, they tried to put an end to this debate
    • 0:04:17and they prescribed that we all just agree to use four spaces consistently.
    • 0:04:23Tabs versus spaces-- no tabs, spaces instead.
    • 0:04:26And indeed, typically in something like VS Code,
    • 0:04:28when you hit Tab on your keyboard, depending
    • 0:04:30on how the program is configured, it should generally
    • 0:04:33convert even things like tabs to individual spaces, like four.
    • 0:04:37What about maximum line length?
    • 0:04:39Your code tends to get less and less readable
    • 0:04:41the longer and longer your lines of code get,
    • 0:04:43especially if they start to scroll over the screen.
    • 0:04:45So Python too tries to standardize what the maximum line length is.
    • 0:04:49You just shouldn't go past a certain number of characters
    • 0:04:51to the right of your screen.
    • 0:04:53Blank lines-- using some number of blank lines,
    • 0:04:56for instance, between blocks of code, perhaps among comments
    • 0:04:59also just lends itself to making your code more readable.
    • 0:05:01Why?
    • 0:05:02Because it's not just a wall of text, a wall
    • 0:05:04of code that you or other programmers have to see by adding in blank lines.
    • 0:05:08And whitespace, more generally, can make it a little easier
    • 0:05:10to wrap your mind around what's going on.
    • 0:05:13And then imports-- even something like this,
    • 0:05:14when you're importing this library or that, or this module or package,
    • 0:05:18Python too prescribes just how and where you should generally
    • 0:05:21put those lines of code that say import or from.
    • 0:05:24And Python, via PEP 8, also prescribes any number of details as well.
    • 0:05:28And
    • 0:05:29These aren't details that we necessarily preach along the way,
    • 0:05:33but rather practice as we write each of these examples in class.
    • 0:05:36And it turns out, too, that as you see more and more code, well,
    • 0:05:39you just get accustomed to the certain rules of proposals like these.
    • 0:05:43So how do you go about, though, checking if your code is
    • 0:05:46in conformance with something like PEP 8, or a style guide more generally?
    • 0:05:50Well, you can certainly read the style guide itself
    • 0:05:53and then look at your own code, and compare the two left and right.
    • 0:05:55And decide, oh, I need to fix this and this other thing in my own code.
    • 0:05:59But there's also tools, being programmers,
    • 0:06:01that can help us solve these problems as well.
    • 0:06:03And one of the most popular in the world of Python
    • 0:06:05is a program called pylint, which is an example of what's
    • 0:06:08generally known as a linter, which is a program that rather statically
    • 0:06:11analyzes.
    • 0:06:12That is-- reads your code top to bottom, left to right,
    • 0:06:15and tries to figure out if there are potentially mistakes therein,
    • 0:06:18or at least inconsistencies with something like a prescribed style
    • 0:06:22guide.
    • 0:06:23This is something that you can install via the usual ways,
    • 0:06:26using something like pip.
    • 0:06:27And its documentation is here.
    • 0:06:28But it turns out there's other tools out there as well that are perhaps
    • 0:06:32a little less noisy than pylint.
    • 0:06:33It turns out if you run pylint on most of the programs
    • 0:06:36you've written thus far, odds are you're going
    • 0:06:38to be overwhelmed with just how many things you apparently did wrong
    • 0:06:41stylistically, even though your code may very well be both correct
    • 0:06:45and well designed.
    • 0:06:46So a little less noisy, at least initially,
    • 0:06:49might be this program here, that's the de facto standard within the Python
    • 0:06:52community for formatting your code for you.
    • 0:06:55Pycodestyle, formerly known as PEP 8--
    • 0:06:58a program as well-- is a program that you can not only
    • 0:07:01run on your computer, documented at this URL here,
    • 0:07:04it will actually take care of the process of reformatting
    • 0:07:07your code for you if it's a bit messy.
    • 0:07:09That is, if the style of your code, your indentation and blank lines
    • 0:07:14and other details as well, are not in accordance with the style guide,
    • 0:07:17something like pycodestyle will just fix it for you.
    • 0:07:20But another one, an alternative nowadays that's
    • 0:07:22actually gaining steam, that's perhaps even more popular nowadays,
    • 0:07:25quite simply called black.
    • 0:07:27And black is a program that you too can install with pip here,
    • 0:07:30and it's documented at this URL.
    • 0:07:32And the etymology of the name black is actually
    • 0:07:34an allusion to Henry Ford, who invented cars way back when, and only
    • 0:07:39sold quite a few black models of the same.
    • 0:07:42And indeed, he's generally known as saying a quote along these lines,
    • 0:07:46any customer can have a car painted any color that he
    • 0:07:49wants, so long that it is black.
    • 0:07:51So if you think about that for a moment, it's not quite a choice.
    • 0:07:54And indeed, that's the spirit of this particular formatter called black,
    • 0:07:58which is that it's opinionated, more so than others.
    • 0:08:01With a lot of these formatters that exist out there, you tend to--
    • 0:08:05or your company tends to, or your course tends
    • 0:08:07to configure them with certain rules.
    • 0:08:09So there might be different ways to do indentation.
    • 0:08:11There might be different ways to do imports or blank lines,
    • 0:08:15and different companies and different people
    • 0:08:17might reasonably disagree, and therefore have their own style guide here,
    • 0:08:20their own style guide there.
    • 0:08:22And it just tends to waste a lot of time, is the thinking, if all of us
    • 0:08:26don't even agree on some of these basics.
    • 0:08:28So this particular formatter, called black, is opinionated in the sense
    • 0:08:32that it just makes a lot of these decisions for you.
    • 0:08:34And if you don't like the way black is formatting your code, tough--
    • 0:08:38tough, that's the way it's going to do it.
    • 0:08:40And this is a trend, perhaps now, at least within the Python community,
    • 0:08:43of quibbling a little less over these stylistic details
    • 0:08:46so that you and I can ultimately focus all the more on writing good code
    • 0:08:50and solving actual problems.
    • 0:08:52And let's go ahead and do just this.
    • 0:08:54Let me go ahead and open up vscode here, where in advance I've
    • 0:08:56created a program called students.py, whose purpose in life
    • 0:09:00is just to create at the top of this program
    • 0:09:02a dictionary containing key value pairs, the keys of which
    • 0:09:05are the names of some students, the values of which
    • 0:09:08are the houses at Hogwarts in which they live, and then I've just got a for loop
    • 0:09:11here that iterates over each of those students,
    • 0:09:13printing out for now each of their names.
    • 0:09:15You can imagine certainly doing more with the values as well,
    • 0:09:18but for now, this is a simple program.
    • 0:09:20But it's already manifesting poor style, arguably-- certainly
    • 0:09:24inconsistent with PEP 8 itself.
    • 0:09:26And I know this from just experience, eyeballing it, and realizing, wow,
    • 0:09:29this is not a good thing that this first line of code
    • 0:09:31goes completely off my own screen.
    • 0:09:33Feels like it's probably a little long-- and I'm
    • 0:09:35going to have to scroll to even see what's going on.
    • 0:09:38And this one's more subtle, but if you look at line three
    • 0:09:40here, even though I've indented technically sufficiently-- so
    • 0:09:44long as my code is indented underneath the for loop,
    • 0:09:47and any subsequent indentation, if I had more lines of code,
    • 0:09:50were similarly indented, the code would work.
    • 0:09:52And it would be correct.
    • 0:09:54But it just does not accord with PEP 8, which prescribes again,
    • 0:09:58four spaces of indentation at each level.
    • 0:10:01So how can I go about fixing this?
    • 0:10:02Well, if I've already installed one of these formatters,
    • 0:10:05for instance, something like black, I could literally just
    • 0:10:07do this with my terminal window.
    • 0:10:09I'm going to run the command black, space, students.py, and hit enter.
    • 0:10:13And voila, you'll see that the students.py file
    • 0:10:16has been automatically reformatted.
    • 0:10:18And at the top of my file, I have now a dictionary--
    • 0:10:21same dictionary as before, but just so much more readable.
    • 0:10:24Not only does it not wrap around to the edge of the screen,
    • 0:10:27you can also see each of the key values pairs one line at a time.
    • 0:10:32And you can see that it lends itself to even adding more down the road.
    • 0:10:35It turns out it's not incorrect to have a final trailing comma like this,
    • 0:10:40even though it's not strictly necessary here on the new line six.
    • 0:10:43Why?
    • 0:10:44Well, Padma in Ravenclaw is the very last student
    • 0:10:48in this particular dictionary.
    • 0:10:51But just in case, as is often the case, I
    • 0:10:54might go in and start adding more key value pairs later.
    • 0:10:57A common source of mistake is to accidentally forget that, oh,
    • 0:11:00I didn't have a comma there previously.
    • 0:11:01And here I am, adding more key value pairs.
    • 0:11:04So that is the kind of detail that black not only fixes for you,
    • 0:11:07but again, has an opinion on as well.
    • 0:11:10So moving forward, as you write code of your own,
    • 0:11:13it's good to get ingrained into you some of the lessons of and some
    • 0:11:16of the guidelines in a style guide like PEP 8, but know that there's tools,
    • 0:11:20be pycodestyle, or black, or something else altogether,
    • 0:11:23that you can use as a programmer to help you focus more on correctness,
    • 0:11:27more on design, more on solving actual problems,
    • 0:11:29while still ensuring that your code is now automatically formatted as well.
  • CS50.ai
Shortcuts
Before using a shortcut, click at least once on the video itself (to give it "focus") after closing this window.
Play/Pause spacebar or k
Rewind 10 seconds left arrow or j
Fast forward 10 seconds right arrow or l
Previous frame (while paused) ,
Next frame (while paused) .
Decrease playback rate <
Increase playback rate >
Toggle captions on/off c
Toggle mute m
Toggle full screen f or double-click video