Hi everyone, I'm Jeremy Bond and welcome back to the Unity Certified Programmer review material. In this video, we're going to be looking at best practices for C sharp programming. This is things to again make you a good citizen when you're working with other people on your programming team. So, the first thing we're going to look at is conventions, coding conventions. A lot of that is involved in naming conventions for fields and variables. So, let's take a look at the asterax script now and this is the script after the end of course two. So, there's a lot of things in here that you have not seen yet of course. But scrolling down you can see that I am very consistent in my naming convention for things like fields and stuff. I tend to use and this Unity standard is to use camel case for this, which is lowercase, first letter of the field name and then each time they're serving new word in the field name you do a capital letter. You can see here that I have very long field names which makes it really easy for others looking at it to understand it. So, for instance, respawnAppearParticlesPrefab. Even if I never looked at this before, I might think, "Yeah. This is probably the prefab for the particles that happen whenever you appear on a respond." So that's a very well-named field. Other names of fields like say sGM here would not be a very good name for a field unless I had something like this Save Game Manager that was was a consistent thing that across the entire game is named sGM. So, that's generally how I tend to name fields. When you're looking at things like methods, you always want to start a method name with a capital letter. So, look at Awake look at OnDestroy in this screen and both of these start with a capital letter. You can call it capital camel case or I've also heard this called Pascal case because this was a standard use in the pascal programming language. Another thing that you see here is all caps snake case. This is things like GAME-STATE change delegate, PAUSED changed delegate and GAME_STATE. We can scroll to the top and see that I tend to use all caps snake case for static fields and constant fields. You don't see any constants on here but you can see I have all these different static fields that are named in all caps snake case and I believe, yes, here you can see I have constants. Two floats that are constant, that will not change and those again I tend to do in all caps snake case. When I have a private field, as you can see here, even if it is static, I tend to put an underscore before the name and that just helps me personally understand that that is a private field. If we scroll down here, you can see that some of the private fields here are named with an underscore, like underscore _gameSTATE and underscore _paused. You can also see that I'm using a lot of these compiler attributes; like header, serialized field, tooltip, those are all things that you should be familiar with and frankly all things that I have found very, very useful in my development. Another thing to point out here is a place where I differ from the Unity standard and that is I love putting these tabs before the names of my field, so that all the field names line up. Normally, that's not part of the Unity standard. I prefer it. I think it makes it easier to read the code and so that's what I do and when I'm working on a team with people that's what we decide to do. The next thing I'd like to talk about is bracing conventions. So, a brace is sometimes known as a curly bracket and it is the little thing there that you can see on line 12. The Unity standard that you see in a lot of the Unity documentation looks more like this, where it is the braces at the end of the line on say static public Vector3 ComponentDivide or public static class Vector3Extensions. However, this sort of Microsoft C sharp standard is more like this, where the braces are on the following line. Lots of my students that I work with tend to have taken classes in pure science where they're told to put it on the following line and the Microsoft standard is to put on the following line and in Visual Studio. If you auto format the code, it will put it on the following line. So, given all of those things even though it differs from the standard that you see in a lot of Unity documentation, I tend to put it on the following line. The key importance here is that you work with your team to decide this ahead of time and then everybody always does the same thing. Another thing that you can see here that I wanted to talk about earlier but I actually had a bug in Visual Studio when I was recording an earlier video, is this really cool auto documentation thing that you see here. You can see this on like lines three through ten, where it says summary and then pair up for paragraph and this kind of stuff. What this does is whenever I mouse over Vector3Extensions, anywhere in the code, you see this pop-up that talks about it, it says a collection of extension methods or one method for Vector3s and this is what is up there on lines like 5 and 6. The pair up puts the line breaks in and this is a really great way to work with other people effectively by documenting your code well and this shows up no matter where I am in my project here, if I mouse over Vector3 extensions, it will do this. Another place you can see this is in the ComponentDivide extension method that is just below. If we scroll down a little bit, you can see that when I mouse over component divide, it gives me all the information from the documentation above and it splits on paragraph breaks and then there are the params there where I can mouse over V0 and it tells me, "Oh, this is the numerator and I mouse over V1." It tells me, "Oh, this is the denominator." So, that's all the information that I would need to be able to use this even if I had not programmed it myself. All of this about documentation and commenting leads us to a really key point which is anytime I think to myself, "Oh, this is a really clever way to do this." That is an alarm alerting me that I need to document it well. So, that includes things like the summaries that we've looked at as well as inline comments, block comments, whatever you want, just document your code because if someone else is looking at it or if you're looking at it a few months from now if it's clever, the chance that they will understand it is far lower. So, anytime you're doing something clever, really, really document it as much as you can with comments and summaries like this. So, the next thing I want to talk about his code modularity and reusability. Now, back in the day when I was frequently working by myself, I would develop these really long scripts that did everything in the game and that made it very, very difficult not only for anyone else to jump in on the project and help me out with things, but also for me to ever go back and modify code. So, I've got a couple of nightmare games that I need to go back and change something in but I know that that script is like a couple of thousand lines long, which is a terrible idea. What you want to do is really think about trying to create small reusable components and the example of that that we have in asterax. The earliest example that you see is the screen wrapper, which is attached to the bullet, it's attached to the player ship and it's attached to every asteroid and it just wraps all of them around the screen. So, let's take a look at that real quick. So here, I've selected my PlayerShip and my hierarchy, and you can see the Off Screen Wrapper there. Double-click on it and it opens up, and this is the same for the bullet or the asteroid or the PlayerShip, it's all the same. That means, I'm not repeating code, it's not like part of the bulletScript and part of the asteroid script or something crazy like that. It's really quite short, I mean it's only 84 lines long, including a lot of debugging stuff that I did and other things like that, and so, it's small, it does a specific thing, and it's reusable. This fits the component pattern that was part of the Gang of Four's book about object oriented programming patterns, and we're going to put information about that book right here so you can take a look at it if you want. This book was a landmark encoding and object oriented code design. A book you should definitely know about is by Robert Nystrom. It's called Game Programming Patterns, and it takes those programming patterns from this original book and updates them specifically for game development. I highly recommend it and you can go to this Website and check it out and read the entire book for free on the website. I do that with my advanced students in my advanced programming class. Now, one more thing about the component pattern is you're already using it in everything you do in Unity, and that's with the components on your game objects. Those all follow the component pattern. So for example, the rigid body knows how to move all these game objects and have them respond to physics, and they can work with any collider component. So sure, there's Sphere, and Box colliders, and Capsule colliders, and Mesh colliders now, but you could write your own collider, that worked within the requirements of a collider component, and the rigid body would be able to use it even if it was entirely something custom that you created, and that's one of the real benefits of the component pattern. Okay, the next thing I want to talk about is some Unity specific things, that again, make it easy for other people to work with you. We're going to look at this GameOverPanel that you can see here in the inspector. You can see it's got active states, a pause effect, and each one of these is set out in a different way. This doesn't look like a mess, this inspector looks pretty clean, and let's take a look at how we did this. So here, the first is, GameOverPanel is the child of ActiveOnlyDuringSomeGameStates. So, if we open that up, you could see here that I have two public fields, one is activeStates, the other one is pauseEffect, and activeStates has this EnumFlagsAttribute, which is part of the EnumFlagsAttributePropertyDrawer that I talked about in the solution to the scripting needs challenge. What this does is these two, set it up to where you see the pause effect is a standard pop-up that happens when you have an enum, but this active states actually allows you to check multiple things and set everything or nothing. So, that's really cool. Then you can see that there's a header set in inspector and that is inside of GameOverPanel, I have the header there as the attribute. Then I have a tool tip as well, and the tool tip again, it's really cool just mouse over it and wait, and it will tell you the tool tip information. So, if you're working with other people, this is a great way to give them some documentation of what you mean with the names of your fields. Then, that's it. I tend to use set in inspector for things I want people to set before they run the game and set dynamically for fields that are more informational that show us what's going on. Another super useful attribute here is require component. You'll hear me talk about this throughout this series, but when you require a component and for a script to be attached to a game object, these other components must be attached and that can really save you a ton of headaches later. You don't want to just assume that say there's a rigid body attached to game objects. You want to be sure before you put your script on it that a rigid body is there. Next I'm going to talk briefly about scriptable objects. Scriptable objects are something that you want to get familiar with and they make it really easy for others to work with you. So this for example, is the asteroids scriptable object. You can see up at the top this create asset menu attribute. Actually sets up a menu in Unity to create an asset that is an instance of this asteroids scriptable object. So, let's go back to unity and see how that works. Now, back in unity, you can see that if I go into the assets menu to create scriptable objects and asteroids scriptural object. It will pop up in my project pane, and I'll create a little demo on here. You can see, that inside here, I can set in the inspector the minimum velocity, the maximum velocity, the maximum angular velocity, the initial size, and all these other fields including Prefabs for the asteroids and Prefabs for asteroid particles. This is the explosion particle that happens. This is really fantastic because it allows us to create several different kind of versions of assets that can be used and set them in the Inspector. In our game, we have it set up to where there's one version for the PC version of the game and one version for the mobile version of the game, which has, the mobile version has simpler collision. The last thing to consider is, when working with other people, you might want to write an editor extension, and I write a lot of these for myself sometimes as well. An editor extension converts the inspector from looking like your standard inspector kind of like you see here for achievement pop up to looking more like what we saw with our game over panel, where there are things that are unique to the editing, and you see this in a lot of really complex and interesting things. One example is if we go to the main camera here. These here, where you see this kind of thing like the First Asteroid Destroyed Event. This is not a standard thing that you would see in the Inspector, but it is the result of an editor extension that makes it easier to edit. Then the last thing to be aware of, is that not all of your scripts are going to extend MonoBehaviour. So, most of them like 95 percent of what our code does extend MonoBehaviour. But for instance, in this achievement manager, I wanted to create a list of achievements and those achievements are complex data objects. So, down at the bottom here, I have a separate class that you can see, I have the documentation of it and the separate class is the class to hold all the information about an achievement. Including the steps like somebody leveled up, somebody fired a bullet, somebody hit an asteroid with a bullet and all these other aspects, and you can see again like for this eStep enum, I have all of this documentation and summary and then when I mouse over eStep here, you can see that all of that summary is listed out and that makes it really easy to use. So, these custom classes are very very useful as long as you don't do anything crazy with them, you can usually set them to system.serializable which allows you to see them and edit them within the Inspector. All right, so that's it. Thank you so much for viewing this video. I'm Jeremy Bond and I look forward to seeing you in the next one. Thanks.
