Hello, and welcome back.
We're starting a new section.
And in this section, I want to talk about some of the basic concepts in C.
I want to describe some of the things that we had in our example or our first challenge,
our main program here.
So I have this challenge up, you probably remember it.
It has a number of different statements in lines of code.
I'm going to try to cover some of the concepts here. I'm going to go back and forth to this example.
The first thing i want to discuss is the concept of a comment.
So we'll come back to this in a second. I want to go to some slides at this point.
So comments are used in a program to document a program and
to enhance its readability.
I told you why it's important to have your program be readable.
Because you're going to be maintaining the code and you need to be able to look at it
and understand what it's doing. So with comments,
it can help quite a bit
in this concept of readability.
Comments are there to remind you or someone else reading your code
what the program is doing or what a particular line of code is doing.
So comments are there for your benefit.
Comments are ignored by the compiler.
So it doesn't matter if you follow the syntax of comments,
the compiler is not going to throw any errors, whatever is inside the comment.
So again, they're very useful and you want to use them in your programs.
And they're a basic concept of all programming languages.
And so there's nothing new really here to see.
Again, you may, as a programmer, write some code,
come back to it in 6 months
and you may not remember why you wrote the code the way you did.
You may not understand the functionality, you may not understand the logic.
By providing a comment in the code,
it can save a significant amount of time that you waste on relearning things,
especially relearning that code.
Or imagine that you wrote some code
and it's a large program, there's many programmers working on it
and somebody else needs to look at that code.
If there's comments and they're describing what the code is doing,
then that other person is going to be able to understand that code much quicker.
It's going to be more readable. So again, comments help the readability
either they help the readability of the programmer who wrote the code
or they help the readability of somebody else that's looking at code.
You can easily look at that source code and then quickly understand what the code is doing.
And so you want to provide comments in your code.
The syntax for providing comments in your code
is there's 2 ways you can provide comments in your code.
And again, this is very, very similar to java, very similar to many languages.
But in c, you can either have multi-line comments or single comments.
If you use 2 characters the forward slash followed by the asterisk,
this will signify a multi-line comment,
a comment that spans many lines.
And the forward slash star marks the beginning of that comment.
And when you have these multi-line comments because they have a starting
comment, you have to have something that says it's ending.
So to end the comments, you put the characters asterisk
forward slash at the end without any spaces in between.
And so then anything in between the forward slash star
and the ending star forward slash
is considered a comment,
everything in blue that. And that way you can span multiple lines.
The other way that you can add a comment to your c program is you can use
single line comments.
Single line comments are just 2 forward slashes.
Anything after the 2 forward slashes on that line
is ignored by the compiler and considered a comment.
Anything after that is not a comment, it's a new line of code.
So it really depends on
the comment that you're providing whether or not you want to use multi-line comments or single line comments.
And I'm going to show you how you can add those to your code in a second.
Now as far as styling goes whether you use multi-line comments
or single line comments, you're probably going to use both depending on what you're trying
to do or how many lines you have to describe or how big your comment is.
In this example, we're using a multi-line comment here,
and this would typically go at the top of the file. It's describing
who wrote the file, the author of the file, and then a copyright.
You can also provide comments that stand out
if something really, really important in your code is happening
by providing many asterisks.
And so the second example here where it says this is a very important comment
it really stands out because of all those asterisks.
So it's kind of a different style than the heading comment at the top
in the first example.
Now the last example here which is just a single line comment,
it's at the end of a line of code and it basically just tells you what a single line is doing.
So you see these different styling of multi-line versus single line comments.
Here's a common example that you would see in a program.
This is a program that contains C code.
You probably don't know really what the heck this is doing.
But you could look at the comments and sort of identify what's going on.
So there's a comment at the top that says this program adds 2 integer values and displays the results.
It's telling you the purpose of the program,
what it's doing.
And then you see some single line comments.
And how do you know they're single line comments? Because they have 2 forward slashes.
So you see a single line comment that says declaring variables.
You see another one that says assign values and calculate their sum.
And then you see one that says display the result.
Each single line comment is describing each single groups of code,
telling you what they're doing.
And so you can quickly look at this code
and understand what the code's doing by looking at the comments.
It makes the program more readable.
Readability is an advantage because it makes the code easier to maintain.
So it's important to use comments. And this is a quick example
of adding comments to some code.
Now how often should we utilize comments.
There is the concept of having too many comments.
You don't want to have your code that has a comment for every single line.
That actually decreases the readability of the code because it's just overflowing.
It's actually making it harder to read because it's just overwhelming.
So you don't want to put a comment for every single line of code.
You have to choose your comments wisely and use them intelligently.
This will come with practice,
when to add comments, when not to add comments, where to put the comments.
Typically, I'll have comments at the top of my source file
with a standard information like the author, the purpose, the description,
the date created of comments, then interspersed throughout my code,
describing some lines of code that where the logic is a little more complicated.
I won't always include comments for just declaring variables because it's kind of obvious.
I may not include comments for certain function,
descriptions because the description itself might be more meaningful.
It all depends and it comes with practice.
But whenever you do add comments, it's traditionally a good idea
to add those comments when you're writing the code.
One because if you do it then, you'll have the program commented
and you won't forget to do it.
It's also easier to document the program
why you actually understand what it's doing while you're writing the code.
Still fresh in your mind, you don't have to come back a month
later and say what did I mean here and now I have to add a comment.
So add the comments while you're writing the code.
And the comments can also help when you're trying to find and fix your errors,
during the debugging phase. If there are logic errors,
you can look at the comments and you can kind of isolate, well,
this is the error that happened.
This comment kind of lines up with that functionality.
I bet you the error is in this group of code. So it helps you isolate errors in debugging.
A comment can help you read through the program, but it can also point the way to the source
of a logic mistake, so comments are important.
Now the other argument when providing comments
is again there's this big debate with programmers, how many comments do you provide?
And there is a nice book out there called Clean Code,
which talks about writing quality code. Believe it or not,
there can be good code or bad code,
and that's referred to as the quality of the code.
You want to write high-quality code.
We'll talk about this throughout the course, but a lot of students that learn new languages think
as long as the output matches what I need,
it doesn't matter how I write the code. That's not true.
Because again, remember that maintenance phase.
Remember that the product or
the program that you release is going to be out in the field maybe for a number of years.
And so if you want to find existing bugs or add new features,
it's important that the code is very high quality, easier to maintain,
very loosely coupled, highly cohesive.
And we'll talk about these concepts as we go through.
We're going to be writing high quality code throughout the class.
One of the ways to write high quality code is providing comments but also providing
self-documented comments.
What this means is really using meaningful names. This is what that Clean Code book talks about.
When you create a variable, use a meaningful name.
So when you look at the variable, you know exactly what it's being used for,
then you don't need to provide a comment.
If you have a function that adds 2 numbers, name the function add 2 numbers.
Do then do you need a comment to say what is that function doing, no.
Because the name is telling you what it's doing.
So meaningful names is a good way to provide self-documenting comments.
Let's go back to our example from our challenge
and I want to show you
exactly how you can add comments and where you add them in.
And you'll notice that the compiler is going to ignore these comments.
So in our first example here which is a basic program,
I'll typically add multi-line comments at the top of the file before any lines of code.
And remember that we can add those multi-line comments by just providing a slash, star,
asterisk to start the comment.
And then anything in between the comment
will be the comment,
anything in between the star and the asterisk.
And you'll notice when I do that slash star that everything is gray
because that's telling me that I don't have my ending comment right now.
So you have to add that star
forward slash to end the comment. And you'll see that the colors now change.
This is why I like to use an IDE because it tells you a lot with this color coordinated
formatting.
So anything between the slash star is the starting of a multi-line comment,
anything before the star forward is the
description or the end of the multi-line comment.
And I'll usually put at the top of the file something like author
and I'll put my name and then I'll put maybe a purpose.
This is usually good practice and I'll put something like this program,
prints out my name to the screen.
And then I'll usually provide a date of when it was created whatever the date is.
And that's an example of multi-line comment top. And then I'll provide comments
throughout the code. Usually single line comments
or multi-line comments, it just depends how much comments there are.
So maybe we're not familiar with this code. And I could say
you know 2 forward slashes is a single line comment. I can say this
code is displaying my name.
And again, when I provide these forward slashes or these multi-line comments,
the compiler ignores them. Basically, you can put anything you want inside there and it doesn't matter.
There's no syntax that you have to follow, there's nothing.
It is ignoring everything that is colored gray here,
that is considered a comment.
So comments are a basic fundamental thing of every program.
I wanted to describe them early on because I'll be utilizing them,
and you should be adding them as you're writing your code.
Also, with comments within the IDE,
there are times when you're compiling your code and it's all failing.
And so there are times when you may want to comment everything or comment
blocks of code to try to debug your problem, try to isolate your error.
You can highlight multi-lines of code
and then you go up to the edit in the menu and you can say
comment or uncomment.
If you say comment, it's going to comment all that code
that you highlighted.
And then you can recompile and maybe you don't have a compiler error anymore.
It's a way of isolating errors either at runtime or compile time.
So the IDE has some nice tools
that allow you to comment multiple lines automatically by highlighting
and toggling.