Hi. When it comes to development, certainly the most foremost concern is whether or not it works. But beyond that, there are a number of other factors that we will consider when we talk about is the code good? So, this goes beyond designer requirements. This is implementation. One of the most important parts of that could be coding style. Coding style is not function, it's form. And there are a lot of defensible choices, alternatives that you have to decide. And really, it's all about consistency. What we want to be able to do with coding style is enforce a coding style guide, a set of rules for formatting code across the entire team. And the reason that's important is because when you stop developing just for yourself, where you're the only person looking at your code, and you start working with others, is that you have to look at other people's code. Now, left to their own devices, developers tend to develop their own personal coding style on their own, their own personal coding fingerprint. It's relatively natural. However, almost no one's coding style is naturally the same. So when you work with a team, what we don't want to worry about is thinking through why does it look like this? Does this imply something? Or even worse, the style choices implying meaning that's different than the way you understand, because of the way that you code. So, we have to consider a lot of different rules with coding style. There are a number of elements to consider, and I won't go into all of it, obviously. We're going to have some other resources that you can look at, some real coding style guides, one from Google, for example, that we'll talk more about, and the wide breadth of things that you can talk about and decide as a group. But I'm going to talk about just a few of them, to give you some examples of what good coding style might look like. With naming conventions, one thing you really want to be able to do is very quickly determine whether some of these are variable names, versus a routine name. This is very important when it comes to things like function pointers, when it comes to looking at places where there aren't nice parentheses that you see over here that identify typical methods, routines, subroutines procedures, whatever. We look at usually one of two things, either it's underscore driven. So, in between each word, there's an underscore, as you can see in the "variable_name" on the left version. And then there's a couple of ways of going about writing method names. So, what you see here is the first letter of every word capitalized, versus something like maybe camel case, where the first letter is not uppercase but then every succeeding letter would be upper case, something like that. Just deciding which one to use, even if it's not going to make a functional difference which one you pick, or even mixing and matching the same code, what it will do is lower the cognitive load of someone reading your code for the first time, trying to understand that code. Because instead of deciding do they mean something different than what I mean? If we can go in with an understanding of this is how it's supposed to look, they have to spend less brain cycles deciding is there meaning behind the format or do I just understand it differently up front? The same thing is true when differentiating classes versus objects. So, the class is a Widget, the object that's instantiated will be "my_widget". Those kinds of differences make it easier to understand what part goes where when you're writing the actual code. When it comes to member variables that are part of a class, we typically also identify them separately. So, what you may have seen in early programming classes is a method where you accept a new value of a variable of some kind. So let's say its "length", and what you end up seeing is that set_length() of the parameter name is "length", so is the member name. You see something weird like "length = length", or you could do something odd with the parameter names, and let it know that it's the length in, or the incoming value, or new length, something like that. To quickly differentiate, one way we can get around it, and still be able to very quickly identify which are which is with the underscore idea, where it's very common to see in style guides either prefixing, or suffixing the member variable name with the underscore, to identify it as the member variable, wherever it's used. So, it's very quickly to see that's going to underscore in the front, that's the member variable. So, where does this come from? That's very easy to see quickly. We can also talk about naming conventions, when it comes to file names. Really, what you want to do is just pick a format. We don't want anyone to misunderstand that a file name doesn't really make a difference, just be consistent. So it's very common to use underscores and dashes, or nothing at all, if you see the three examples on the screen here. Whether you use one or another really doesn't matter all that much. What we will notice, however, is that there are no spaces in these examples. So file names on a Windows platform does allow spaces, but that breaks immediately on any *nix 90% of the time. So if you move from Windows to Linux, Windows to Mac, potentially, those files with spaces in the middle will cause lots of programs and scripts to fail. So, we want to generally say while this style doesn't really matter in general, you want to be consistent, and you don't want to use spaces in your file names. There can also be differences with extensions. So for example, in C++, the examples on the screen here are examples of that. These all have the ".cc" extension. You can also use ".cpp". We've even seen others that have all of the code in ".h", the header file for the working file, that's what the "h" extension would mean. You have all the code just in that one file. You just have to decide. Well, it's common to have a ".cc", a ".h" or a ".cpp", and a ".h" corresponding files. Just pick something, and again, be consistent. A lot of this is just being consistent so you don't spend brain cycles deciding what to do with these things. Another one of what some experts continually argue about, you'll see an example where one of the resources that will take you to an article that talks about indentation, tabs versus spaces. There are a number of comments where it's a long-standing debate about whether or not to use tabs versus spaces is the right way to go about indentation. It's less important than about consistency again. It's less important than I want to make sure that when I'm indenting to show that it's something is nested, I indent one level. That's the important thing. However you indent by however much tabs or spaces, you indent once per nesting level. There might even be special rules for indentation when you get to the end of line links. So for example, many code style guides like the C++ style got from Google will say I want every line to end at 80 characters long. Every line should end in 80 characters. And if it's not going to do that, you need to somehow word wrap manually. You need to put in a line break yourself at 80 characters. Then you're allowed to wrap the content down one line. But, we want to differentiate between the line break and the actual body of the code by indenting them differently. So, what you normally see is if you're indenting once for the content interior of the block, you indent twice for the line break of a single line. If you actually had to do a new line that continues a single line, do that word wrap. Another of the great debates is the placement of braces. There are, generally speaking, three accepted versions of the placement of braces. And I know even saying that out loud is going to get some people upset with me. But generally speaking, we see one of these three choices when it comes to placement of braces, K&R, one total bracket system, 1TBS, and Allman. So with K&R, what it really comes down to is this, is that for any method, you have the opening and closing brackets on their own line lining up vertically so you can quickly see where the method begins and ends. Then inside the function blocks, or the method block, you'll see the code have a bracket at the end of the line, like you see in the if statement there in the K&R example. You can also leave out the brackets if the statement is only one line long. So, for example, in the else there there's only one line in that block, so there's no brackets. 1TBS goes further than that, and says no, you can't avoid the brackets for the else. Even if it's one line, even though functionally it would work, we don't do that. We always put in the brackets, so that it's not possible to confuse where the else starts and ends. In addition, rather than having the bracket on its own line, it moves it up to continue the method signature on that first line, rather than having the opening bracket for every method on its own line. So, it really keeps everything consistent. The brackets are always at the end of the line. Now, that is, again, separate then Allman. You can see almost immediately that it's longer. It does the same consistency that 1TBS does, but it goes the other direction, where every opening bracket has its own line. It doesn't matter whether it's for a method, or for the If block, or a While, it always has its own line. You can see even the Else statement there has its own line. This tends to make Allman code a little bit longer visually, but it does help solve one of the issues where developers like having vertical up and down alignment for every set of brackets. So they know exactly what line each individual nested block starts and stops, without having to look at the end of the line to find the opening bracket. Use of white space, so this is also important. Now, there's another example of this in another lecture. So, I'm going to be very specific in talking about placing pointer symbols, rather than kind of all the rest of them, and they can make a real difference in understanding. Look at these three examples. All three are functionally valid. They all work, because for the most part, the compiler doesn't really care about the spacing. They don't care about white space. That's going to be a double pointer called "a", that's just what it is. It doesn't matter where the star is, next to either one, or separated from everything. But it does make a difference when it comes to understanding when we read it as humans. So look at the final line, is "b" a double, or a double pointer? Does that asterisk apply to both "a" and "b", or just "a"? If you look at the spacing, it could be either one. But the program actually works in one of the ways. So, you really should match the general understanding of the symbol, so that everyone understands the meaning of this. In C++, it's "double *a,b" because only "a" is the pointer. The star only applies to the first variable. It doesn't cascade like the data type does, so it is attached to the individual variables. So with you spacing and having the star late and next to the "a" to designate that, you don't have to spend as much time thinking. If you're in C++, and you see the first version where the star is next to double, you might accidentally second-guess yourself, and think that it's double pointer for all of them. Completely misunderstanding, and assuming that "b" is also a pointer, when it's not. Coding style really is a matter of ease of understanding. We're trying to ease the cognitive load for anyone coming in, and trying to read the code itself for understanding. Consistency allows the reader to focus on the logic, rather than why does it look like this? Could that mean something different? Thankfully, a lot of developers have their own style. There are automated processes and tools that exist to help developers either stay in a style, or even change style. So, the automated tools for checking style issues. So, if I run my code through a style checker, it will tell me all the things that are wrong according to the style guide, or at least as much as they can programmatically find. There are even others that will automatically format your code for you. Beautification, especially when it comes to brace placement, indentation, that kind of thing. It can automatically format it. They come in a number of different formats, but there are ones for generally every single language that will allow you to just put your code however you want it, and put it into a beautifier. And the beautifier will change it to meet the coding style guide that you actually have to have when you submit your code to the repository.
