In this video, we'll discuss code style, which is something that is near and dear to my heart. Style describes how your code is formatted, which is independent from what the code actually does. Not only will good style get you a better grade in CS50, but it will also help you write code that is much more readable and maintainable, which, at the end of the day, is going to make your life a lot easier. The three main components of code style that we'll discuss this video are comments, formatting, and variable names. Let's start with comments. Remember, comments have no effect on the functionality of your code. They only serve as helpful hints to us as programmers. Good comments should answer one of two questions. First, what does this block of code do? This is a short and sweet description of the purpose of the lines that follow. For example, you might need to find the place where you implemented a particular feature to fix a bug or change something. Without comments, you may need to pore over many lines of code trying to figure out exactly where that feature is. Or if it's been a few days since you've looked at one of your programs, you might not remember what a particular function or loop does. So comments will make reacquainting yourself with old code, or acquainting yourself with someone else's code, much smoother. The second question a good comment answers is why did I implement this block in this way? As you write code, you'll frequently need to make design decisions. Should I use a while loop or a for loop here? Should I make this block of code into a separate function? Using comments, you can document your design decisions, which will make your code easier to understand for others, who may be asking themselves the exact same design questions as they read your code. Or even yourself, if you come back to a block of code after some period of time. In C, and the other languages we'll see in CS50, there are two ways of adding comments to your code, in-line comments and multi-line comments. In-line comments are great for documenting pieces of code within functions. For example, an in-line comment could describe the purpose of a for loop or a corner case that necessitates a condition. Multi-line comments are great for documenting functions. Whenever you write a function, you should always, always, always document what it does with a comment. This includes what the inputs to the function are, what the output of the function is, and maybe why the function is implemented in the way that it is. Whenever you change a function's signature, return value, or implementation, it's important to also update the corresponding documentation comment. A mismatch between a function's comment and implementation can be really confusing for readers. Similarly, creating a multi-line comment at the top of each .c or .h file you write, describing what the file does, is also a very good idea. As you're commenting your code, one of the first questions you might have is, well, how much should I comment my code? It's often unnecessary to document every single line of code. For example, a line that says int x = 5 doesn't need a comment about it that says "set x to 5". Not commenting enough, though, as we've seen, can make understanding your code very difficult. So a good rule of thumb is to comment interesting blocks of code, where a block consists of a few related lines. So let's take a look at an example. Here's an uncommented C function. Okay, since this is a function, the first thing we need to add is a comment explaining what the function's inputs are and what it does. So let's add a multi-line comment. Great. Now we know exactly what our function does. Let's add some in-line comments now. We can divide our code into two blocks of similar lines. Lines 4 and 5 construct strings based on the input and lines 6 through 9 output those strings within song lyrics. So let's document that with comments. Awesome. Now our function is commented. Notice that our in-line comments don't need to use complete sentences or end with a period. It's important that there's a space between the second slash and the start of the comment. This is the frequency of comments within your programs that you should be shooting for. Notice here how we separated the two blocks of related code inside of our chorus function with an extra carriage return. This brings us to the next component of code style, formatting. When I first started programming, I hit the Enter key very infrequently, which resulted in giant, unreadable blobs of code. I think I actually offended my teaching fellow, since she wasn't too happy with me. Visually grouping blocks of related code, using carriage returns, can make your code easier to skim and clearly delineate which lines of code your comments are explaining. That being said, spreading out your code too much, as with two or more lines between code blocks or functions, can also make it much less readable. Indentation is another important aspect of code format. Always, always, always indent the body of a function, loop, or condition. This makes it clear which lines of code are inside a loop, for example, and which lines of code are outside of that. CS50 recommends that you indent with four spaces, but if you choose something else, be sure to be consistent throughout your code. On that note, CS50 recommends that you place braces on their own line. That way, braces will line up visually at the same left margin, so it's crystal clear where a block begins and ends. However, it's also okay to place braces on the same line as a condition, for example, to conserve space. If you do this, though, make sure you include a space before the curly brace so it's not smooshed next to a closing paren or a word. Whichever you choose, the most important thing is to be consistent throughout your code. What we don't want to see, though, is indented curly braces. Doing so makes the braces appear disconnected from the condition, loop, or function they're demarcating, making the code hard to read. In C and the other languages we'll see, curly braces are optional for single line conditions or loops. It's fine to omit curly braces in this case, but if you do so, be sure to be consistent throughout your code. When defining functions, CS50 recommends you write the return type of the function on the same line as the name of the function. However, it's also OK to write the return type on its own line, which can make function definitions easier to find in some text editors. Finally, be sure to include spaces around keywords and operators. For example, a line that says int x = 5 is much easier to read if there are spaces around the equal sign. Similarly, make sure you have a space after keywords like if, for, and while. Without a space, these could look like function calls, which they are not. So let's take a look at an example of applying good style to a badly formatted block of code. Okay, let's start from the top. We can see that the opening brace of main is on the same line as the function's name. If we're going to do this, there must be a space between the closing paren and the brace, like this. However, CS50 recommends that braces stand on their own line. So let's do that. Now that we're in the body of the main function, we'll need to start indenting code; we'll use the recommended four spaces. Next, we see that there's no space around the equal sign here, so let's add that. Here, we see that there is no space between the if and the open paren, so let's add that, along with some space around the greater than sign. Again, we see there's no space between the closing paren and the opening brace here. If we're going to put these on the same line, there needs to be a space before the curly brace. However, it looks like the body of our condition is only one line. So we don't need to include the braces at all. We now need to be sure to indent at the body of each of our conditions. We definitely don't want this last line to be on the same line as else, so let's hit Enter and indent. Finally, the closing curly brace for main needs to be on its own line. We can see here we have two different blocks of related code. Lines 4 through 6 prompt the user for input and the remaining lines display that input to the user. So it makes sense to put some space between these two blocks for clarity. And there we go; now this code is much easier to read with good style. Finally, let's talk about our third component of good style: variable names. Your variable names should describe the value that they represent. Let's revisit our earlier example. Bottles is a good descriptive name for the variable that represents how many bottles are left on the wall. Names like x or numBots are not very descriptive and are not good for the readability of your code. While variables named by a single letter are common in math and other fields, they can make your code very hard to understand. The exception to this rule is iterator variables inside loops. In for loops, for example, it's fine to use variable names like i, j, and k for iteration. When creating iterator variables within loops, it's recommended that you do so within the loop itself, rather than outside of the loop, so that we can keep variables as tightly scoped as possible. On the other hand, a variable name like number of bottles left on the wall is, while descriptive, overly verbose and not necessary. In the event you do want to create a variable with multiple words, separate those words with underscores. For example, is_ready is much more readable than isReady. It's fine to declare multiple variables on the same line. However, if you do so, don't initialize some variables but not others. That means something like int dimes, pennies semicolon, is OK. But int dimes = 0, pennies semicolon is not. Finally, when declaring pointers, it's recommended that you place the asterisk next to the pointer's type, not the name of the variable. So int* p is recommended rather than int space *p. Whoo! So that seems like a lot of rules to remember, but don't worry. If ever in doubt, don't hesitate to refer to CS50's online style guide. Let's quickly summarize the important points of code style. First, comment your code. Always, always, always describe what functions do with a multi-line comment and comment every few lines of code in-line. Second. Be consistent with your code formatting. Pay attention to your placement and usage of braces as well as spacing around keywords and operators. Finally, choose descriptive variable names. Variables should describe the value they represent, but shouldn't take you forever to type. And that's it. All of this will quickly become second nature as you write more and more code, and you'll be coding with style in no time. My name is Tommy, and this is CS50.