Hi. In this video, we're going to look at some more examples of what we mean by coding style and how it can affect not only the way it looks, the way it is easy to read, but also really understanding of the code itself. So, looking at these examples is going to be better than talking about them. If you haven't already looked at the coding style video or you don't really understand coding style, I would strongly recommend you go and watch that video first. A lot of this is still form over function, but choices have to be made. So, let's look at some of the examples. Take a look at this code snippet. What does it do? What potential problems does this pose to developers unfamiliar with the codebase? Pause, then take a second, think about this line of code. The spacing between the operands of a multiplication operator, it makes it look like the additions happen first. That's not how it works. The compiler or interpreter will in nearly all cases ignore the whitespace here and use the normal order of precedence for mathematical operators. Multiplication and therefore division happen before addition and therefore substraction. This is a trivial example to be sure, but it highlights the importance of this. Anyone reading this code can very quickly and easily mistake this for implying precedence, you can't have that. That's why there are very important rules about how we write coding style. So, for example, requiring that all operands have a space on both sides or no space on both sides. As long as it's consistent, you don't accidentally imply or infer understanding or meaning from the change in style. Here's example 2, take a second and read through that. It's a mess, but it's perfectly fine for the machine. It doesn't see whitespace like we do. Coding style isn't about functionality, it's not about how the program understands our code, it's about us as humans trying to read it. The computer would be fine replacing all the variables with "x1", "x2", "x3", "x4". It doesn't make a difference to the compiler, those are just labels, but for us it does matter. So, this is generally speaking bad. Let's try and fix it a little bit. That's better, we've added some new lines, we've separated some of the work, but it's still not ideal. Certainly, it's a little easier to understand, basically one thing is on one line, that's generally good, but it does not exactly help us understand. We usually want to add indentation. In this version, I've chosen to go with two spaces for each indentation level, this allows us more quickly, at least to see what's included in what construct. So, you can see in the right column of the code that ends with a While, they're all indented, they all exist within the For loop, and you can see after the For loop, the indentation reverts back to the single set. While you're in the While loop, you get two sets of indentation. You can clearly see the "data [ insertPos ] = ", all that it's on different nesting levels, and then the variable declarations "insertVal", "insertPos", they're up at the beginning of the For loop. This allows us to much more easily understand the code and the code's purpose. So again, indentation really does matter, it really does play a part in understanding the code quickly. There's certainly additional aspects to code style, it's not just about spacing and layout. Most style guides also dictate a variety of naming conventions. We'll talk about that in the other video. But self-documenting code is also a big factor, and most style guides do talk about when you should self-document and how. You might see something like this. Sure, there's a method name and you should name it well. This is comppoly(). It could mean a number of different things. I hope for the most part that it would be "compute polynomials" because that's what it seems like it's doing, but you don't really know. What's worse is, it's relatively hard to say, especially if you don't really read through the code that much. If you just look at the return statement, well, that's y2, what's y1? I don't know what those are. The variable names aren't conducive to understanding. It's a lot easier when you self-document where each element of the code actually explain it's purpose, so that I don't need context, I don't need to read the entire thing to understand. I can see that the second array in the quadratic formula parameter is a quadratic function, I know that's what they are. It says so in the name. Now, there are arguments about this. Well, this is longer code where there's more bits, it takes up more space. Yeah, but remember that the compiler is going to take and try and optimize a lot of this. It's not going to hold the actual name "line_param". It's going to replace that with something the computer understands, pointers more likely, memory addresses. So, the length of the names, generally speaking, it doesn't really make that much of an impact. Now, it could be a big deal with something that has very low space or processing power, embedded devices and other things, medical devices. That might really make a difference. But for the most part, we also have tools that really focus that down and optimized for space, optimizing for memory. In fact, compilers do that quite often. So for the most part, we should be looking at making it readable more than anything else, more than the other concerns, and that's probably true for 90% of programming, maybe more. It really does seem simple until you see examples of poor style, style that's not your own. You don't really understand or internalize the benefits of a coding style until you don't have one, and then you work with code that you can't understand, that it's hard to read. So, it's supposed to ease understanding for the reader. There are a lot of choices you need to make, consistency is the main key. For the most part, what you'll see is that people will adopt some already existing coding style and then maybe make some modifications. There are a number of popular examples. We'll post some references and talk about a couple. So, you can go see the full breadth of all the things that would go into building a true style guide.
