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