Okay, so I sort of purposely skipped over one of the really
basic features that pretty much every programming language
has, and that's code commenting.
Now you've probably actually seen this before where I just
write a number sign and then anything in here,
and as soon as I hit 'Enter', Python does not complain, but
if I type anything in here, it's going to complain.
Now the difference is this is a code comment.
Anything after this symbol here is considered a comment,
and Python just says, "Oh, that's not for me.
That's probably for my human overlords.
So don't do anything with it".
Now comments are a really good way of maintaining your code.
It is a very healthy habit to get into,
and I would say whenever you can, comment your code; and the
more complex your code gets, the more comments it probably
needs. So let's just start fresh here, and let's say we have
a variable called 'name', and it's going to say, "What is your
name?", and it's just going to ask for someone's name.
Now we could put a comment here saying, "# This will ask for
the user's name".
And so whenever someone comes into your code and they say,
"Oh, what is name?"
'name = "What is your name?" They can also read the
comment that says, "# This will ask for the users name".
Now, we are familiar with the 'input' function by now, so we
know what this is going to do, but someone else may not.
Another example of this could be a dictionary called 'person',
and we could try to get someone's 'age'.
And so we can say, 'person.get('age')'. Now by default,
'get' always returns 'None' if there is nothing there.
But because that's a default parameter, you don't actually
need to specify that.
A lot of people, surprisingly don't actually know that.
So what you could say in this comment, is "#Get the person's
age or return None", or not return because it's not,
I guess it could return, or assign, rather, "assign None if
an age wasn't found".
And so it's going to ask what my name is, that doesn't really
matter. My name is "Kalob", and the 'age' here we do 'age',
it's nothing. 'type(age)'
is 'NoneType' because there was no age in here, it defaulted
to 'None'.
And that's a good use of using comments.
Now another place you're going to want to use comments, and
you'll see these all over the place,
is inside of functions as well.
So let's create a function 'def 'func_name', and it's going to
do a thing, so 'return "Something in here"'.
Now you can leave comments in here as well.
So, "#This is going to do a thing".
It's a terrible code comment, by the way, because it's not
very explicit. It doesn't tell you what it's going to do.
It just says it's going to do a thing. That's not helpful.
So when you're writing your code comments, try to be a little bit
better than me in this demo video.
But in a function, there's another way to write code comments,
and this thing is called a Docstring.
So it starts with either three apostrophes, or it's going
to start with three quotation marks.
I like using the quotation marks, but it doesn't really matter
which one you decide to use.
And then here you could say, "This is a function that does
a thing", and then, "It's going to return a string", and maybe
some other notes.
Now, we saw this when we were learning about strings
way, way, way, way back
there are lot of videos ago, but this is called a Docstring.
And so what you can do,
is have multiple lines in here, and you don't have to worry
about putting a number sign in front of every single line.
It prevents this from needing to happen.
[no audio]
Now, one last reason to write comments,
a lot of people when they're just learning to program, they
say, "Oh, I don't need to write comments.
I know exactly what I'm doing.
I know myself well enough to understand why I named a variable that."
And for the most part, that could very well be true.
But three months from now, six months from now, nine months
from now, you are going to have a lot of different experiences
between now and then, and your brain is actually going to
change a little bit, and you may not fully understand or
fully remember all the code that you wrote.
So writing comments like Docstrings here is really helpful.
So nine months from now, you could look at 'func_name', and
you could say, "What is it supposed to do?
Like, I don't understand why you even have this in here".
But in the Docstrings, this could say, "This is a demo function
and is not used at all.
It's allowed to be deleted in the future".
Let's go ahead and get rid of this stuff.
And so when you come back to this code nine months from now,
you can say 'func_name'.
"This is a demo function, and is not used at all. It's
allowed to be deleted in the future".
Okay, so I've got a comment in here that tells me that this
is likely not being used, so I could probably safely delete
this. The other reason is you are going to be working with
other people. Other programmers, other Python Devs are going
to be looking at your code eventually, and you're going to
be looking at their code,
and if they have some complex function, you're going to want to
know what it does, just like they're going to want to
know what your code is doing, so leaving a comment is very, very helpful.
Now, when it comes to basic things, for instance, a 'role
= 'Student',
well, that's pretty self explanatory,
talking about a 'role = 'Student'.
Now, we don't necessarily know what that 'role' is
for, that might be worthy of a comment.
But you don't need to leave a comment like, "This is a string",
because anyone who's looking at this code is going to say,
"Oh, that's obviously a string. I know that".
So this is an example of a bad comment.
Actually, I shouldn't say it's a bad comment, but it is a
rather useless comment,
everyone's going to know that this is a string.
Now, if there was a bunch of logic in here, let's say there is
30 lines of code, and this 'role' is going to change into
maybe from a 'Student',
it takes a string, and eventually it gets transformed into
like a User Id, which is going to be an integer,
then you might want to comment that because, again, there's
something a little more complex, not just on the surface,
but something complex that's happening in your code,
that's worth commenting.
So my advice is comment.
And if you're ever wondering, "Kalob, where should I comment?
Should I comment a particular function?
Should I comment a string?"
Honestly, I'm just going to tell you this right now,
it is better to leave a bad comment than to leave no comments
at all. 100% of the time
it is better to leave a bad comment than no comment at all.
[no audio]