Do Standards Matter in gamedev?

hey what's up I'm Jason and today I want to talk about something important and I think a little bit funny the more I think about it the funnier I think it is which is kind of weird and especially when it comes to game development so think about when you start working at a new company you start working at a game company or even an on game company or maybe I'd say this applies less if you open up just an open source project but it may apply there too but generally when you start working at a game company one of the first things that you'll get as a programmer is a link to some internal dock that has coding standards on it and they'll say hey here's the coding standards go check them out and you may have seen these before if you've worked at places that don't have these then hey hang on because this is gonna get even better you've really been missing out so the places with the coding standards Doc's usually what happens is they send you a link you get this email they go hey did you go check it out and you go yeah I went through and read and it was a little bit of info about how to case things and maybe how to abbreviate things and what things should be named a lot of the time they're like a one-page doc or sometimes it's a slightly longer doc and you'll read it understand it and then you'll go look at the code and go oh wait is this new like is this a new coding standard doc that you guys just wrote up and we're working on switching over to that or what's going on here and you find out oh no that Doc's been there since the start just nobody actually follows the damn thing right everybody just does whatever they want everybody uses their own standards and it's a big giant mess yeah I think like hey why does that matter who cares like whatever let me code the way I want to code and let my buddy over there code the way he wants to code the problem is that when people get into your code it gets confusing as hell so if one person's doing things one way another person's doing things completely different way maybe one section of the code is all linked statements another section it's no linked statements at all and all this other stuff with weird abbreviations and then another spot you get the idea things can get messy really fast and really really confusing coding standards are there for a reason it's supposed to be an agreement that you make with your team everybody comes together and you say hey this is how we want it to look this is what perfect code would look like so let's make our code look like perfect code for some reason though everybody will make those agreements and then just ignore him or just say hey I'll fix it later or ad they're not doing it there so I won't do it here and there are a couple reasons that this happens before I dive into the actual standards which I'm gonna do in just a moment so if you're looking for those you can skip ahead or just hold on also if you want to hold dock of all these coding standards leave a comment below if there's enough of them I'll put the dock together and then I'll put it in the description and you'll be able to go grab it if there's no interest then whatever but if there's enough comments down there I'll go do that right away so anyway why does this happen why do people ignore the coding standards why do people get all of these cool rules for how to make perfect code and then say hey we don't care we don't want the perfect code what what actually happens usually the scenario that I've seen is that the coding standards dock is put together in the wrong way and it's not the formatting or the rules that are wrong it's the process that what happens is one person often the lead or the first person will go in and write up this dock based on how they write their code and then that becomes the rule and everybody else goes yeah I see that but I think it's a little bit wrong here so I'm just gonna ignore that part and then the next person comes in and does the same thing ignores two parts but it does things a little bit one way and a little bit the other guys way and then a little bit their own way and it starts to get worse and worse and then it kind of grows and becomes a mess and suddenly your coding standards dock is just a useless lie right it's a piece of trash that nobody believes cuz nobody uses it so what's the right process for me I think that the perfect process is one where you come together with your team you get all of the programmers together and you say hey let's figure out what we want this to be let's figure out the rules for each of these different things how do we want our code to look what should it look like how should things be named all that kind of stuff and you write those rules together you agree on them live together in a call what where you're talking I would say even turn on video if your remote or be in the same room and just write it all down whatever you do don't do asynchronous stuff try to get it as synchronous is possible yeah so that you're working together and live now before I dive into the details of each of these coding standards I just wanted to briefly show an example of a coding standards dock that I just found by doing a quick Google search so here you see he's got classes and interfaces how to name them what to do for methods what to do for feet those parameters names how to set up his braces and a couple other very small rules now let's dive into some coding standards that I actually use on my own projects and we're gonna do that by going through this weapon class file to start and we're gonna begin with casing just like that document that we just looked at did because I think it's an important part that sets a precedent through your entire code base if your casing is wrong everything else is probably a giant mess - so let's start with the first rule of casing on line seven here we've got our weapon class and it is Pascal case so we have an upper case W and if you look at our monobehaviour unity also follows this same rule capital m and a capital B so we capitalize each word of our class names and we always do that also the file name always should match the class name and it should match that same capitalization so make sure that you're not breaking that rule now let's go on to line 9 constants and making them scream if you look here I'm in writer and writer actually recommends that I change it it says hey constant fields should be Pascal case they shouldn't be this screaming all uppercase with an underscore I personally disagree because I don't use constants very often and when I do have them I want it to be very obvious that it's a constant because most of the time I would say 99% of the time if I see something Pascal case like that I'm going to think property in my head I'm gonna think ok I'm just accessing a property and I can probably do some other stuff with it and a lot of the time I don't want that I don't want to be confused and think like okay is something changing this property is this property variable like the biggest reason that I want to know that the thing is a constant is because it just locks it in my head this is not going to change I don't have to worry about it so spelling it out that it is a constant with this all uppercase and underscore gives me a lot of value and I still recommend it to everybody and by the way just for anybody who's not familiar with constants the whole concept here is that this value here my reload time can not change this Const keyword just makes it so that the value can't change at runtime it gets compiled down and essentially this reload time gets replaced with a 0.3 everywhere in the code when the runs all right let's go on to the next one line 11 here we have our private int underscore ammo in clip and this says underscore and camelcase are private fields this is also a point of contention a lot of the time and the reason for that is that not the camel case camel case is very common for private fields but there's always a lot of contention about whether or not to use an underscore I have used an underscore for a lot of them and then switched away from it and realize the pain of losing it and switched right back to it so I generally always recommend putting an underscore before a private variable again the biggest reason for this is immediate instant knowledge of whether or not this is a parameter or a class specific private or protected field if it's got an underscore I know it's definitely not a parameter I can instantly just kind of get that extra context without thinking about it and it doesn't add a lot of noise I find that the underscore is the least intrusive way to do this I've seen other people use things like M underscore which was I believe meant to be member of the class and the underscore but I feel it adds a lot more noise the underscore because it's just a subtle little line doesn't do much but it gives you just enough context to know what it is so an underscore and camelcase for all private fields and you'll notice as we go down to 13 and 14 I do the same for protected fields and again this is also a point of contention sometimes some people disagree but I would recommend going with the underscore for your protected fields as well as your private ones public ones no but protected and private definitely and you see if Ryder again disagrees with me on protected fields I still just find the value there in the underscore knowing that it's a member of the class and not a parameter that's where I really care about the differentiation next I want to talk about public properties or even private properties all properties and the property is just a field or somewhat like field but with a getter or a getter and a setter and here I've got it a little bit confusing so let's convert our expression body property on line 16 over to a normal property where we have the getter so say we've got a property like this where it has a get and it returned something the proper casing here is Pascal case and no matter what the property is if you have a getter or you have a setter Pascal casing is generally the way to go now I want to dive into properties a little bit more though because we're already looking at one and I want to point out that I generally would recommend using an expression body property when it applies when it fits in a scenario like this if you're just getting something and doing an evaluation try replacing your get statement with just this little lambda operator this equals greater than operator what this is gonna do is replace your getter with whatever this is so the response Ford has ammo will just return back this whenever you call the get on it which is essentially just saying hey if has ammo what you can see on line 20 so expression body properties highly recommended also expression body methods when there's only one action in there if it fits on a line convert it over and simplify things but also more importantly Pascal case for properties always go with that even if it's a private property that's just doing some calculation I always go with Pascal case there so what about methods so I've got a fire app method on line 18 this would be a method for my weapon to fire at some target we have two naming conventions here first we have the name of the method fire app which would be in Pascal case and then we have the parameters like our target to damage and these are always in camel case so Pascal case for the method and camel case for the parameters and if you look down at line 25 you'll see the last of them which is camel case for local variables too and this is really all of the rules that you have for casing there's not a lot to it it's just very important that you stick to it and keep it standardized if you keep to these rules it's very easy to know if something's private if it's public if it's a class if it's a field that's improperly exposed or something else so stick to these good casing rules and let's go on to the next one now I want to talk about one of the worst offenders and this is the thing that I see happen all the time and it drives me completely insane and this is abbreviations and as you can see here I've abbreviated our weapon class to show just how beautiful it can look and how much harder we can make it to understand just save a little tiny bit of screen width here so I've got my class renamed to WP because if you don't know it's a weapon too bad you're out of luck right and then I've got my reload time there as our LT just in case you're wondering and then a IC which probably means something oh yeah our ammo in clip right so you get the idea we can have abbreviations for things we can shorten the crap out of these things and make the names confusing so that if you're right in the mind a set of it and you remember exactly what it was and you just wrote the code you know exactly what it is and you saved yourself an extra three finger strokes but in a second you come back and read it or anybody else reads it they get confused as hell so do not abbreviate things almost ever there are a few very small scenarios where I would say abbreviations are acceptable things like the word min and Max instead of minimum and maximum or where there's a domain-specific abbreviation that everybody working on the project is going to understand or that it only makes sense for your project like if you're working on some HIPAA compliance don't spell out the entire whatever HIPAA stands for you know just write HIPAA or whatever the thing is the abbreviation that is common and makes sense for that context but don't abbreviate your words and your variable names just to shorten them in fact always I'd say avoid abbreviating them spell them out and be very explicit with what they are naming is the number one most important thing in your game or in your code well it's an yeah it's the number one most important thing there are other things that are important too but I'm gonna say naming is number one at least the number one easy thing to hit so don't screw it up and don't abbreviate and since we're talking about naming let's briefly dive into nouns versus verbs and what are classes and methods should be named so our classes in general almost always should be a noun they should be an object a thing a person a place like a rocket launcher a player a level or a mountain or whatever it is it should be a noun a physical thing or thing that you can visualize in your head as an object the methods however should be verbs these should be actions or things that we do so we've got a rocket launcher that's a noun it's object and it fires they rocket straight that is the method or the verb and all of our methods should be verbs like this so we've got fire rocket straight as a verb we also have a rocket that's a class and that is a noun so if you look we're getting a rocket from get rocket and pool which is again a verb to get the rocket from the pool and the rocket is going to be the noun or the object and then we're telling the rocket to launch another method or verb so just we want to stick with the standard of nouns for met classes and verbs for methods it makes it so it's very easy to understand what our code is doing and how to interact with in how to work with our code in a very logical way now that we've talked about casing and naming let's talk briefly about what order things should be in how should your classes be laid out and what should this look like I personally think that it's pretty important to keep things standardized and keep things in a consistent order in a way that makes it easy for everybody to understand so let's go over my preferred order I like to start with constants up at the top I do again don't use them very often but when I do I want them to be very spelled out that hey there's some constant that this class really cares about and it's probably special and important and has some special meaning so you should know about it then I go on to static stuff because I find that these get misused or misunderstood a lot and it's very easy to get confused when a variable is static especially if it's mixed and kind of buried in between things so making sure that static things are very obvious and called out is very important to me so I like to put these right at the top as well next I'll put in my serialized fields because these are the things that designers are going to customize and edit and if there are gonna be quite a few of them I like them to be right at the top most of the time I don't have a lot of serialized fields I'll have one or none so it's not a big issue but in the cases where I have a lot of them I really want them to be very visible and right up at the top next I'll go with public properties because I assume that these are things that other classes are going to be interacting with so I'll put my public properties there with the Pascal case and then I follow up with something that I think may be a little bit different but it's private properties and that's just because I like to keep all of these properties that could or could not be calculating all in a single area so my public and private properties all of these that secretly could hide a little bit of complexity are in the same spot and I don't have to go digging for them next I'd go with private fields because I think that they're a little bit less important to have visible but I want to have all of my fields in the same area all of my properties and fields public or private I want all of that data to be right up near the top so that I can figure out all of the data that's in my class and I don't have to dig through the class to figure out what other data this class knows about now ideally before I dive into the rest of this I want to point out that ideally our class should fit on a single screen at a time so I should be able to see all of my class all at once and understand it and absorb it that's almost never the case that's a rare but ideal scenario most of the time though it should be at least under a hundred lines so if it's starting to get too large and there's too much data in here that I have to literate it around to be able to know where it is it's better to start thinking about maybe I should split this class up into multiple maybe this class is doing too many things and it should be kind of spread apart or refactored or extracted let's jump back in to order so after private variables is when I dive into awake and you can see here that we're all the way down to line 19 to be honest a lot of the time I don't have this many things up above are awake and it just starts off with one or two properties or one or two fields and an awake then we go into update now I also want to point out with awake I don't just mean awake it could be awake it could be a start method it could be awake and start or if it's non monobehaviour you have just a regular old class which a lot of your files should be it could just be the constructor I think of a wake and start as almost constructor replacements more of a wake as a constructor of replacement though so just remember that all three of those could be in there in any scenario and I would probably go with awake and then start because that's the order that are called in if you're gonna use both next update so update is called often it should be right up at the top so that I know that this thing is doing something in an update and I can understand what it is and I can even just quickly briefly look and expand it and say okay it's just taking damage one damage every frame I'm sure that sounds like a great game playing mechanic right so let's jump into the next part which is public methods so after update I will put all of my public methods some people like to put their public methods up a bit higher so that they can see what they're getting called but I personally like to think of update as a public method even though it's private it's being called by something external and the control of that isn't necessarily internal so I like to just think of it kind of the same I care about what update is doing just as much as I care about these public methods and a lot of the time there's not a lot of mix or not a lot of overlap if I have an update there probably aren't many public methods and if I have a lot of public methods there probably isn't an update there following the public methods is private methods because these are only cared about by the code in the class so I shove these down at the bottom and I want to dive into the last and I think most important part of this ordering which is keeping them in order that they're called or the I think it was called the newspaper or foldout method so that as we go through the code and as I read it the code calling me is always above me so if I look at set weapons set weapon is actually called by die so I can kind of read this in order and die if I expand out take damage is actually called by take damage so I can be in here and let's just zoom in say I've got imagine I've got a little bit more code here and this is a real class or with a lot of stuff going on I'm reading I see take damage I go through ok reduces health and if it gets too low it goes into die and then die is right down below it and okay that goes into set weapon okay and then that goes into here and does some weapon setting and it's very important to keep these things as easily chained or easily read as possible you want to be able to just scroll through it understand what it's doing and not have to hit the hotkeys to bounce around in your code so much if you have to keep switching around in code and going back and switching all over the file you're flipping around and you get the idea it gets to be a lot harder to understand what's going on if you can keep things in this order where they're nice and organized it makes a big difference it's also worth noting that sometimes things can't be in order I may have set weapon calling take damage or maybe die is calling something else that it has to be up above it's okay if they have to be out of order but the goal is try to keep them as in order as possible to make them easy to read music understand if they get too wild and too out of order you may have too big of classes but still just try to keep them as clean as possible now let's talk about some very important rules for properties and properties should be littered throughout your code so it's important to get these right and make sure that you standardize on these and you kind of decide what to do but my rules are number one for a public property I try to default to not having a setter this doesn't mean that I don't add a setter but by default I don't add a setter I don't say hey public float speed gets that I just say public float speed with a getter and then once I need a setter I'll add it and if I do add a setter the next step is to add a private setter so that it can only be modified by the code in this class I almost never have a setter that's public where they get and a set it usually means that I'm breaking some encapsulation rules or that I'm exposing too much so I try to avoid it but sometimes I have them and I live with that I just want to point that out it's not a hard rule but just try to prefer not having those wouldn't it make sense or when you can now the next part is a hard rule and that is naming your properties to match the class that they came from this used to confuse me I used to think I used to think like oh this is a terrible idea now I'm not going to know which one's the member and which one's the class or which one's the definition which one's my actual variable but we have editors now that color all of this stuff and make it very obvious and I don't think that there's an editor out there that doesn't do that I also don't find that I've ever gotten really confused and not understood that I was referencing a static method on a class instead of the instance of the class which is really the only scenario where this could get confusing if the weapon had like a public static method on it you can maybe get a little confused but I would say always prefer to name your variable the same as the proper the class name because it makes it a lot easier to understand what it is and you don't have to come up with two names that somehow link together and make sense but aren't exactly the same so make them match Nextup prefer expression body properties when possible so if you have a property that's just a getter that's maybe wrapping something returning back a property of another thing like I have a weapon that's returning earlier I'm returning back my weapons attack speed for this attack speed check here on line 13 if you have something like that go with an expression body property if it will all fit on there and it's easy to understand and you don't have some weird logic in there do the expression body property if you have to add in a bunch of weird ternary operators and make it confusing and hard to understand then don't do that but in a case where it's easy go with that it makes it simpler to read easier to understand just reduces some of that litterin mess now I want to talk about the most important part here for properties even more important than naming them right which is that your setters for properties should not do things other than validation they have the ability to do code run code in there it's primarily there for validation and event orchestration if you use it to do weird things like killing your player and persisting them to the database you will find that somebody's going to misuse it it might be you in the future it might be a co-worker that goes hey I want to set health to this I'm just gonna set it at every frame because it doesn't matter right not realizing that oh yeah the setter on this does something stupid and calls out to the database in your spam database in cup gamer or whatever it is this is a very extreme scenario but it's one that I have seen where it calls to a setter were causing database persistence and just killing performance because somebody didn't understand or didn't realize that setting this value was a very costly thing when it's something costly something that's gonna be a big call like this don't make it a setter on a variable it gets confusing it's very hide that easy to hide it I should say and hard to understand what's going on so never do something in the setter other than validation or sending out an event fit the value changed don't go beyond that don't make it more confusing now I'm going through my list and I've got about a dozen other recommendations so I think what I am going to do is turn all of this into a doc and make it available for you so if you're watching this and you're interested in this no drop comment down below just to make sure that I know that you're interested in it and you probably all see the doc down below too so just go grab it and you can go through all of my recommendations in writing and maybe use that as a basis to start your own coding doc again I also want to really really point out that you should not go create a coding doc and just send it off to your team and say hey team here's our coding doc instead get together with a completely blank doc pull up some examples and some ideas of the things that you want to use and build that doc together come together as a team put it together and agree on it as a team it'll be a whole lot easier to stick to and a whole lot easier to make sure that your code actually follows the doc and it's not just some wasted thing that sits off there that you just give to new people to go check out follow for a weekend ignore so stick to coding standards do do the right thing try to make it easier for yourself it's gonna be better for you and your team you'll probably enjoy the results online you will definitely enjoy the results if you can get everybody to follow these standards or follow some set of standards and do things right now I wanted to say special thanks to everybody on patreon really do appreciate you guys and I also wanted to say please hit like and subscribe and share the video with everybody know hey thanks again for everybody for watching appreciate it if you guys have questions or your other own recommendations on coding standards drop them in the comments below - it'd be kind of curious to get some more ideas and maybe build this into a very big coding standard stock that everybody can use alright thanks again bye I'll shut up now you

Channel: Jason Weimann

Views: 22,749

Keywords: game development, game dev, game design, indie game development, coding standards, unity3d, unity, unreal, unity 3d, c#, unity code, game programming, brackeys, sykoo, game programmer, game developer, video game, game programmer interview, coding standards, coding standards in c#, coding standards in programming, programming, coding, code quality, code, clean code, best practice, computer science (field)

Id: NQ6P7ecpdlY

Length: 26min 12sec (1572 seconds)

Published: Sun Apr 05 2020