Hello, my name is Matt Vorce. And today I'm going to talk about some programming best practices. Quick overview is basically I'm just going to go over some of the practices that I've learned over the years I've been programming in Unity. First I'll start out with code style. Coding style is kind of a personal topic, and it can be hard to get programmers to agree on what's the best style. The best thing to do for yourself is to pick a coding style and try to stick with it. As you start a project, you should talk with the other programmers on the team and try to come to a consensus on what type of coding style you want to follow. And then when in doubt, when you're working in an existing file, try to match the code style of that file. If you look at the .NET standard, it's recommended that you use Pascal case for public numbers, classes, methods, and properties such as these shown here. And when you're looking at function parameters or local variables, use Camel casing, as you can see in this function example here. The .NET standard is less specific when it comes to private variables. As for myself, I prefer to start my private variables with a leading underscore, some people prefer to use a leading m underscore. The way you name your classes and functions is very important. Typically, you want to name your classes after a noun. The reason for this is they represent objects inside your application. Looking at functions, you should try and name your functions after a verb. The reason for this is the functions execute an action within your application and should be named as such. The decision to make a variable public versus private can be a big decision. Often I see too many programmers making things public for no good reason. Public variables should be used sparingly throughout your application because they require extra consideration. The thing about public variables is they can easily be changed anywhere else in your code base even if you didn't intend them to. And it can be a lot harder to track down what class was responsible for changing those variables. It often can lead to bad practices as well, code that can be too interdependent, or a code that is just less object oriented in nature. Here's an example of how you might debug a public variable that has changed without your knowledge. You would first have to search the codebase for all areas that could be potentially changing that variable. You could then add debug statements or put debug break points at each of those points to try to determine which class was responsible for the change. Now, if you had instead put that variable into a property, you could debug one spot in order to determine where the change was made. Properties are always a good option to use. Here I have an example of a private variable which has a public property so that other classes can get inside this variable. This is another example of the same property which is much shorter. The downside of this approach is it will not be picked up by the Unity Serializer, and therefore you wouldn't be able to set this in the inspector. Unity allows you to use something called serialized field. What this does is allows you to have a private variable which can also be set via the inspector. If you do this, Unity will automatically remove a leading m underscore, underscore from the beginning of the variable name. This way the variable will still be very designer friendly. Another topic that should be looked at is refactoring. You should always refactor code early and often. MonoDevelop and Visual Studio give you a lot of tools that you can use for this refactoring. Some examples include extracting a method, which is basically grabbing a chunk of code and putting it into a method, renaming all your variables, functions, and classes. These things can be done very easily. You should never duplicate code. Make your functions as simple to understand as possible. Renaming parts of your code is a very important step in refactoring. There is many reasons why you might rename a variable, class, or function. For example, the purpose of it may change. You may find that the name does not explain it well enough and you're confused about what it does. You may also find yourself needing to heavily comment in order to explain what the variable class or function does. Or you may just think of a better name. All of these are valid reasons of why you might rename something. As you get farther along in a project, you'll often realize that the functionality needs to change, and along with it, the code must change as well. This is another reason why renaming is so important. Modern Development Visual Studio allow you to quickly rename functions, variables, or classes by simply right-clicking them and selecting rename. Or you can press the F2 key. When it comes to your member variables, you should always separate them by access type. In the example here you see I've got a number of different variables all mixed together. Below is a better example where I've separated them by their access type. It is common practice to have all member variables at the top of your class. I prefer to put the public member variables at the top because they are the highest priority, and followed by the protected and private variables. Just as member variables are grouped together, you should always group your functions by access type. This helps someone else to quickly scan your code and figure out how to use it. I like to group my functions into regions, such as public, private, protected, or special unity routine functions such as start, awake, or update. Another important concept in Unity programming is the idea of awake versus start. You should always prefer to use awake instead of start. Unity likes to default their scripts with start, instead of awake, so often people use it instead. My philosophy is that you should always do initialization work as early as possible, and that would mean awake. You should then run any code that needs to interact with other classes in start. This way you give those other classes time to initialize themselves via awake. For example here, I've initialized a camera in awake, and then in start, I've initialized another member variable that relies on an existing class in start. If awake and start can't get you what you need, you can then turn to the script execution order. This can be accessed through Edit > Project Settings > Script Execution Order. You can use this to guarantee that certain scripts will run before other scripts, this includes the awake, start, and update functions. Next I'm going to talk a little bit about commenting. Commenting can be a great thing for helping people understand your code, but you don't want to go overboard. Always avoid needless comments such as the one below. Comments on functions can also be helpful. If you find yourself needing to comment a large block of code, chances are that you need to refactor it. Take chunks of the code and try to extract them into smaller, reusable functions. Let the code comment itself by making functions small and by choosing proper names. Using good naming goes 100 times farther than having lots of comments. If you use the triple slash comment, it will give you free intellisense on your functions.
