🌍 FREE C# Beginner Complete Course! ruclips.net/video/pReR6Z9rK-o/видео.html 🔴 Watch my Complete FREE Game Dev Course! 🌍 ruclips.net/video/AmGSEH7QcDg/видео.html 🌍 HumbleBundle MEGAPACK cmonkey.co/humblebundle ✅ Unity Summer Sale (ends soon) assetstore.unity.com/?aid=1101l96nj&pubref=notpublic 🌍 Get my Complete Courses! ✅ unitycodemonkey.com/courses 👍 Learn to make awesome games step-by-step from start to finish.
Я новичёк: Ненавижу приватные переменные. Целую гору кода писать для того, чтобы достать информацию из этой переменной или её туда записать. Кодеры странные люди: могут продумать весь функционал программы, что на какие классы разбить и какой функционал должен быть у этих классов, но не могут запомнить что player.speed = 10 это изменение скорости персонажа, а не чтение? Уверен, что видео должно называться: Why you should NOT make EVERYTHING poblic! Вам нужно посмотреть фильм "Yes Man". Сначала ты используешь "public" везде, потом тебе говорят что это плохо, и ты везде используешь "private", а потом понимаешь, что там где нужно закрыть переменную, и подписать на изменение этой переменной какое-то событие, то используешь "private", а во всех остальных случаях "public"
In my 4 years of code learning, the public variables become 20% more private each year. I am still lazy about making all private even in cases that I know it should be. But I will get there. Thank you so much for the great videos.
4 years were thrown into the trash. How lazy you must be so that you don't want to think for at least 3 seconds about whether you need to give the variable public access. I'm not even talking about the SerializeField attribute. If you're not going to work and you make games only as an indie developer, then okay. But anyway you didn't have «code learning», you didn't learn how to code.
You got to all riled up about the dude leaving public variables, but I worked in a big tech company and you can't imagine how many big programmers (seniors, 15+ years xp) working in huge application projects just leave public variables left and right. It is a bad practice and doubles the workload sure. But it's not a mortal sin. Relax man, you sound stressed.
@@eloreneloreneloreneloreneloren Dude that was too harsh, relax. Even people with tons of experience sometimes leave public variables thinking it will be needed that way in the future, and just forget about them past the time. It's a bad practice but no one is going to die due to that, just more workload.
@@eloreneloreneloreneloreneloren Jesus Christ m8, no need to be so harsh. If you didn’t know about it then there’s no need to be so harsh. They aren’t showing an ego and they aren’t Being an ass about it so no need to be an ass
The best example I've come across as to why you should make fields private and use functions to access them is to think of it like a device such as a TV remote. Do you need to know how a remote works in order to use it? Nope. As long as you have the buttons needed to perform its function, that's all that matters. In fact, if late at night a bunch of garden gnomes sneak into your house, and completely change the inner-workings of the remote and then leave - if the next time you use it and it still functions the same, you won't notice the difference. In a similar manner, the public entities of a class are those "buttons", and other classes should use those without having to "know" how they are defined as long as the expected result is achieved. You should make it in a way such that you can change the way your class works without affecting code in other classes.
Hey Monkey, this video should naturally continue with using a property for public reading but private writing and also you should check out the benefits of using scriptable objects as variables because it avoids dependencies and unnecessary errors. I admire what you do for the community! Cheers!
Events are also good for reducing dependencies but it becomes ever more important to have good documentation as you may not receive errors in the console when things are not working properly.
if you want to take it to another step, fields should NEVER be public. They should be exposed through properties or methods (just do a quick Google search on Properties vs public fields). In C# you can create a public auto properties like this: public float Speed { get; set; } //The naming convention for Properties is PascalCase However in Unity, public properties will not be exposed in the Inspector, this is because a Property is literally just a layer of abstraction which includes a private backing field and two public methods, you can think of the property I declared above like this: private float speed; public void SetSpeed{float value} => speed = value; public float GetSpeed() => return speed; So in order to expose Properties to the inspector, you have to expose the backing field (which is normally hidden if you use auto properties) by using the [field: SerializeField] attribute, which basically tells the compiler to apply [SerializeField] attribute to the backing field of this property. [field : SerializeField] public float Speed { get; set; }
What I also like about SerielizedField is that you can put further atributes to it, like Range() or Min(). That way you can clamp the value you can give in the editor.
You just blew my mind. Like, seriously, thank you. I have so many code in OnSerialize() that was there solely for the purpose of me not accidentally setting incorrect value to the variables...
I just started learning C# for Unity specifically (about a week or so in). The series I've been watching has been great so far but I questioned this the second it was introduced. I absolutely asked myself, "Why would you make anything private ever?" Glad I got my answer, how serendipitous.
Got the megapack, very glad I could find a way to support your channel. You make much better tutorials than anyone else I've seen, and I direct aspiring Unity developers to you whenever I can. A big thanks for all the informative videos you've made, I will always be a silent supporter of your channel.
There is 2 things that I do to make a cleaner code : as you said in the video, I avoid as much as possible the public field, and when I make a public variable or a public function, I also add a comment to clarify the other classes/objects that use this variable/function.
I dont use unity but to just keep learning about everything makes me happy. I would love to see you make more videos about clean code. Very interesting and helpful
as a beginner I think learning serializefield is super important because of this exact reason. I find it very helpful when applying this to prefabs where you need a different variable in each situation.
This is quite a contentious topic. Making everything private by default is what is thought in schools and is a generally accepted good practice. Personally however, I find that non-public access is more trouble than it's worth. Every field, method, class and whatever I write is always public. There are several reasons for this. First: The language allows you to access private fields anyway, it's called reflection. Second: You have to provide access to all your fields anyway (through methods/properties). You may think that you don't have to but if other people end up using your code then someone sometime is going to want to access that private field. An example for unity: extending the animator. If you try this you will find that a lot of the fields are non-public, forcing you to use reflection.
Well, that's signs of bad coding practices. Reflection for instance is a VERY costly operation that should be used only if you have no other choice, so if you find yourself using it more than a few times then the design of your logic is clearly wrong. Even more so if it used every frame. Likewise, it's better to use protected abstract and virtual functions to allow people to write their custom logic via child class if they need to, because it provides even better flexibility at no cost.
@@oldcat1790 it's all fun and games when you call your code from your code. Using other people code, especially old code, especially in ways it was not made to be used makes it a different story. And yes, it is a smell, but it is a better approach to use at most protected so user can do something that is outside your assumptions. Else you need reflection or other such hacks to get what you want.
Thanks, as a self taught coder many of this basic concept of OOP alludes me (and i just follow them blindly because of "good practice"), and yes, you're the first one that explains the concept clearly
Code Monkey, thank you for keeping and not removing subtitles that are automatically generated by RUclips (even if the speech does not always match what is written in the subtitles). This allows me to translate them into my language (russian) and watch your videos.😜
I think part of the reason for beginnings to use public for everything is not yet knowing how to make Actions, Events, Accessors, Interfaces, and Constructors work. I would say I'm intermediate level and only just coming to grasp with these myself, but starting to internalize it and using them more and more.
I watched this video shortly after it came out, and after watching your video from yesterday (Difference between Transform & GameObject), I decided to check this out again since you mentioned it. I was curious if everything you said in this video had stuck, and I'm glad to say that it has! I realise this is quite basic compared to most other concepts, but even a reminder on "simple" things goes a long way sometimes. You're honestly a great teacher, Code Monkey. Thank you for all the amazing content and courses you've made.
Thanks for the book recommendation! I saw this video while I was planning to learn unity, saw the book and decided to wait on watching the rest of the video till I read it. I just reached 6.2, where it talks about this, and so far, this book has taught me a lot! Thanks!
After remaking my project from scratch and use private most part of the time and not public as i used to do i had the same conclusion of this video, public variables are like those bikes with training wheels, they're great for complete begginers, but as time goes on and things get more complex, the training wheels most part of the time will only limit what experienced people can do instead of helping
I haven't used public variables for almost 2 years. If I have to access the variable I create a property like public float Speed => speed; so they can access it but can't change it. for changing I use methods which is also still a rare case
I have made some games before but I still had some doubts regarding why something should be public or private. This is a great explanation, thank you very much!!!
Man you are speaking wisdoms in every video you make. Also when you said that the only limitation is the developer experience not Unity, that powerful words convinced me not to distract myself switching between Platforms. Thank you man🌹
One thing I like to do is have readonly accessors for my private fields if other classes need that information. So if we have private float speed; we would also have public float Speed => speed; so that we can read the speed value but not write it. Also => in this case is the short hand for public float Speed { get { return speed; } } You can also do this for functions too if it's a single line
The ominous "accidental modification". There is a cost in hiding access: it create lots of additional boilerplate code for public getters and setters. The cost is a longer time to scroll to the now longer sourcecode, with the programmer having less overview. Unless the code is ment for others to use, such as in a library or module, adding lots "security" to the code can have a negative effect. It sufficient to make the interface to that module safe.
I'm having a feeling that the "accidental modification" part doesn't really change much with private variables and public functions. If a script has a variable and a function for changing the variable, then how is it any less troublesome to change it from the function, rather than the variable itself? If an error occurs anywhere, this means either the errors are coming from whichever function is accessing it, which was the exact same problem I was having before... Or the problem is actually in the function I created, which means there's a new boilerplate code that I'll have to search as well. Maybe the new function can also include some code that tells who is calling it, but this code might need to be written off in the end for performance issues. The only place where I see are where the function happens to be both complex and general at the same time. For example, when my player dies, the player gameobject disappears along with some extra stuffs to show the player died. If I code all of it newly in every script that can kill me, then it's a lot of code to search for error correction. But if I do one death function to hadle all of it, I can easily check what caused it. But for something so small as getting and setting values, this looks redundant to me.
I'm just starting out with C#, but not unfamiliar with some scripting. Regarding beginner's tutorials teaching to use Public fields: wouldn't it be better to teach the best practice early on? I know it could be a rabbithole of theory before practice, but as a new developer, it can be confusing to learn one way and then discover I should be doing it differently. As I was told when learning piano, "practicing with the wrong technique will only make the learning harder in the long run." However, maybe the important thing is to just jump in, without too much theory, since taking the initial plunge is often the most difficult.
Exactly. Code that is only used internally by one class can be private, there's no harm in doing so, and it will benefit you in the long-term. Unnecessarily publicizing everything will also make your properties explorer a lot more cluttered, since now if you want to edit a variable you're going to have to search through a lot of other variables. I'd only publicize fields if I need to for debug purposes or to tweak values without recompiling every time I change it
C# allows you to define getters and setters that allows to control and access directly to public variables but read and writing will be performed thru getters and setters. That makes obsolete the must-to-be-private members with manually defined getters/setters.
@@CodeMonkeyUnity the point is that using private properties has not advantages over public ones once you can define implicit hidden getters/setters to handle reads/writes to those public properties... no advantages in using privates and all problems and all overhead... I prefer to use private properties only for... really private things that are used in code internals, whose are usually not serializalbe and of course never exposed to the inspector (they are private!!! inspector is the more public-like-thing... making a private property visible for the inspector is like making it super-public).
Thank you for this video, you confirmed what I have thought since a long time now. I would be very interested to see you dive deeper into this topic with getter and setter, or juste using function, buff and debuff ... Very good video for an important thing when it comes to make an ambitious game !
If you want to learn more about clean code I can highly recommend the book Code Complete 2 And I just recently released my latest course which is heavily focused on writing good clean code to take your skills to the next level ruclips.net/video/QDr_pjzedv0/видео.html
I personally prefer to keep things as protected rather than private because it's pretty much the same as private except it makes code written more expandable later on without changing anything.
Great explanation process! I do try to avoid public variables and only using for Game Objects or Transform. You should also do an episode on public static variables. I try as much as I can to stay away from static and rather do properties or pass reference.
@@EvitoCruor You can still use the public static classes for example I will use them for an inventory class. The issue comes when you are getting an error when changing a public static variable and forget where the variable and change is coming from. Most of my games have 60 or more scripts : / better than doing one long script
Thank you! Finally! So many tutorials just toss about the public variables and it's very disappointing. SerializedField is also good for debugging as you can monitor the variable's value in the inspector in real time.
really cool video, I always had the doubt of how to improve the code and not make everything public, I had heard that it was wrong to use public variables and now I understand why, thank you!
This is nice! I do it by default, even when I didn't knew why, I really don't like when i bump into some experienced programmer that says, we'll fix it later (making unnecessary public variables for testing) which end up being part of the code and left as public...
I used to just shrug it off and do it my way, with everything public. Once I got a big enough project, I realized a few of the reasons we shouldn't make everything public. Now, I actually try to anticipate how exposed it'll need to be, and work from private to public.
btw, that public variable you made called `speed` cant be used by other scripts THAT easily. You have to call the script in order to call it's public variables so Idky people act like its the other way around.
This is great advice for beginners moving up to the intermediate level, but I have found that, in moving from the intermediate to advanced level, making things public is almost universally better--though the reasons are nuanced, address long-range issues, and assume some things. The problem with private variables arises when one transitions from writing game logic to tool logic (which is then assembled into game mechanics by juniors or non-programmers). At that point, the logic "only make something public if it has a clear reason to be public" breaks down because you can't possibly know the full range of use-cases in advance and so to lock something down imposes a permanent design limitation based on a lack of imagination. As a specific example, when working with Mecanim, one must maintain a code-based state machine to control characters with animation in addition to the animator state machine and keep both in sync with each other (or work around the system entirely with animator.Play("magicString")...all because someone at Unity couldn't think of a reason to access animation states other than the one currently playing and made that information private. This may sound like an edge case, but over the years, I have lost weeks if not months worth of development time working around tools that have made things private that I needed to access for some reason, and 0.0 seconds debugging problems that arose because something was public that should have been private. Further, in my own programming, I have recently been leaning heavily on a nested composition pattern, where every piece of code has the potential to become a building block for code that operates on a higher level of abstraction, and in that context it is often useful to change settings externally via OnValidate. Another, more nuisance-level problem is what I call "fake encapsulation". For example, this disturbingly-common nonsense: private myVariable; public MyVariable { get => myVariable; set => myVariable = value; } Assuming the above is not to complete an interface, the above pattern adds negative value. In addition to wasting space, it also creates the illusion that myVariable is protected from access from the outside, when in reality it does literally nothing other than require using a capital 'M' to access it. Now, I am making a couple of assumptions that mitigate the benefits of private variables/methods. First, I am assuming one has an IDE with right-click -> find all instances. Second, I am assuming that every...single...time one modifies a variable, especially one in a different script, one does so with a knowledge of the impact of changing that variable and the alternative ways of accomplishing the same goal (as opposed to just looking for something quick that "works"). I take it as an axiom that if new code breaks something, it is ALWAYS the fault of the new, accessing code, and NEVER the fault of the old code not putting up sufficient guard rails. And if the goal is communicating intent, that's what comments are for. By analogy, if a neighbor breaks into my house and steals my computer, the neighbor is to blame for the loss, not me for having insufficient security. Granted, being mindful about how variables are set is certainly good practice. For example, calling a Damage(int value) function instead of directly decreasing health is probably a good idea. This, however, is not for the sake of "protecting" the health state, but for the sake of readability, since damage is the concept being implemented and it just happens to result in decreasing health (possibly among other things).
Calling a Damage(int value) function is not for the sake of "protecting" the health state, but for the sake of keeping an eye on health changes. During debugging you can easily add debug.log into such function, unlike direct changes.
As I said, treating Damage() as a process that happens to involve decreasing health rather than directly accessing the variable makes sense. And yes, having the potential to easily add debugging logic is one benefit of this process framing. That said, in a context where debugging is the only additional consideration--that is, when it actually makes sense to modify the variable directly because that is a better analogy for what is happening than a process--you could do so with setter logic. In any case, my point stands: whenever anyone actually argues that variables should not be public, the stated reason is pretty much always for the sake of "protecting" state, I'm inclined to take them at their word, and I don't consider this a valid reason.
Great video! A similar one could be the implications of singletons as I feel like they are something I used to abuse alot in the early days too (and still do when im lazy.)
Thank you for your wide verity types of videos. Your Chanel is the best for learning unity tips and tricks I just wanted to know if you have a plan doing a series of videos to cover making textures from beginner to pro as they can be used every where?
Interesting but I found making everything public helped me in my coding a lot. I just have a strict rule never to update a public variable in more then one spot and all the code can read it but only updated in one place, so if other things needed to influence it then create new variable for that and still update the main variable in the one place with those adjustments if needed. I also of course use longer and more detailed variable names to reduce conflicts and also a full list of all used variables in a table I can check is not already used elsewhere....not hard and solved a lot of conflict problems that way. The full variable table was good to also sort between what needs to be saved in the game save state and what is not needed. I also have tended towards functional programming which allows local variables that are not global by default anyway (unless I want them to) so also helps a lot in avoiding conflicts.
I don't normally do unit tests for my games since I have to work insanely fast in order to find success with those games, but I am constantly trying to write code that could be testable. So I'm constantly thinking about how to minimize dependencies and make every script as standalone as possible. Unity does have a bunch of Unit Testing tools which I've never used but I'd love to research them when I have the time.
I'm of the mind that you should tend toward protected rather than private. Nothing worse then inheriting a class and needing to change one small thing but you can't because developers are obsessed with making things private. Then you have to duplicate code to achieve what you want because you're not allowed to edit the original source. This happens to me more often than is reasonable contracting for epic.
Some compilers default to private, others to protected. On a class hiding it might make it private, on an interface it will make it public. So it's always best to be clear and specify exactly what accessibility you want.
Just asking : How did you started your game development career? I mean what kind of game engine you used and programming language as well. Just want to know, to have a basic idea. Iam currently having a hard time in using unity. Specially at coding but I love to code and want to do so. Your channel helps a lot to fix them. Thanks for your support through videos. ❤️
I covered my game dev journey here ruclips.net/video/0zscPf_U1VY/видео.html Basically I started making IRC scripts, then moved onto Flash and finally when I wanted to make PC games I found Unity and I've been using it ever since.
2 questions I have about this: 1 - Would this mean having all variables private and setting them trough public methods? 2 - Using this logic, can I still use {public get; private set;}? I say this because having all variables private would make hard to get them on other scripts, so I can use my second question to get them, or use a public method to do so?
Yes exactly and yes you can use properties as accessors. Personally I prefer get() set() functions but properties can work as well, the point is to be able to add some extra logic so you're not accessing the variable directly.
1. what is the difference between a private variable and one with no definition? 2. should you use the hideInInspector atribute when you dont want to modify the variable in the inspector?
1. variables in C# are private by default so you don't need to explictly state private but you should for readability. 2. HideInInspector is only really useful if you aren't using serialized fields. If you don't want it to be in the inspector just use private. I've never found the need for HideInInpector when using clean code principles.
@@Wobling A quick note on your 1st point: - This is true in a class or a struct: members are private unless you explicitly state otherwise. - In an interface or a namespace (or even outside of any namespace), members are public by default. As you mentionned, it's a good practice to explicitly write the accessibility level, even if it becomes redundant with the default behavior.
How would you go about changing a private variable from another script? Like the SetSpeed() you mentioned? Won't public functions make your code less scaleable (I could be misunderstanding something)?
Yes exactly, "less scalable" can also be described as "less accessible" which is exactly the point, you want to limit access as much as possible to limit how many possible things can go wrong. It's much easier to find references of all SetSpeed(); function calls than all read/write direct access to the variable itself.
You should never expose a Field public. If you want to change it, use Methods or Properties. The official C# documentation says: Never expose the inner workings of a class.
except cases when you need to work through the pointer with some of pointer's object's methods so you make it public. Because if you not, you need to make methods to call methods which change private fields
oh my god, no. that's some dumb, old timey, Java verbose nonsense. this video is a disservice to actually writing clean code. yes, you shouldn't expose the inner workings of a class. which includes the inspector! if something is visible in the inspector, then it should be visible from other classes as well! this is literally what every built-in Unity component does!!
So many tutorials use Public variables and it's something that has always annoyed me. Unless you require external access, just make everything private. And a lot of the time if you require external access you can make use of get/set and have much greater control over access (eg make getting the variable public but setting it private etc). And if you need access to private variables via Unity then use [Serializefield] attribute.
I think the real problem is not that field is public but the way those systems are constructed to interact with one each other is inherently hectic. making the variables private doesn't solve nor improve how the system would interact with each other. If anything making things blindly private has the potential to add more complexity to the system since you're adding layers of abstraction to your data fields. Now should you have a bug involving that data field, instead of just looking at who accessing the field directly, you gotta sifting through a bunch of different methods to find the problem.
i justt started learning with Unity. after this video im wondering why i would ever use the public version now instead of a Serializedfield? should i avoid this completly or are there some circumstances where the public version still makes more sense to use? thanks for the great videos btw.! im learning alot from you!
what's the difference between modifying public variable from other function and modifying private variable with its public function from other function
So in my case, i'm trying to make a racing game but have two separate scripts that handle the acceleration and steering of the car and I have code attached to this that decreases the speed of the car by a certain amount when turning. I do this by making a variable for the acceleration script and then modifying the speed variable whenever the player turns (the speed variable itself is public since I can't get access otherwise). I'm still relatively new with programming even though i've been doing it on and off for the past few years so this may seem like a dumb question, but is there a more efficient way that I should be doing this instead of making the speed variable public?
The problem that I face while keeping as much as possible private is that I just dont understand on how to reference something private in one script from another script. It sometimes not work for me even if I copy directly from someone else's scripts
🌍 FREE C# Beginner Complete Course! ruclips.net/video/pReR6Z9rK-o/видео.html
🔴 Watch my Complete FREE Game Dev Course! 🌍 ruclips.net/video/AmGSEH7QcDg/видео.html
🌍 HumbleBundle MEGAPACK cmonkey.co/humblebundle
✅ Unity Summer Sale (ends soon) assetstore.unity.com/?aid=1101l96nj&pubref=notpublic
🌍 Get my Complete Courses! ✅ unitycodemonkey.com/courses
👍 Learn to make awesome games step-by-step from start to finish.
I really can't watch the video with its white theme.
Я новичёк: Ненавижу приватные переменные. Целую гору кода писать для того, чтобы достать информацию из этой переменной или её туда записать. Кодеры странные люди: могут продумать весь функционал программы, что на какие классы разбить и какой функционал должен быть у этих классов, но не могут запомнить что player.speed = 10 это изменение скорости персонажа, а не чтение? Уверен, что видео должно называться: Why you should NOT make EVERYTHING poblic! Вам нужно посмотреть фильм "Yes Man". Сначала ты используешь "public" везде, потом тебе говорят что это плохо, и ты везде используешь "private", а потом понимаешь, что там где нужно закрыть переменную, и подписать на изменение этой переменной какое-то событие, то используешь "private", а во всех остальных случаях "public"
In my 4 years of code learning, the public variables become 20% more private each year. I am still lazy about making all private even in cases that I know it should be. But I will get there. Thank you so much for the great videos.
The goal is to constantly improve over time so it sounds like you're on the right track!
4 years were thrown into the trash. How lazy you must be so that you don't want to think for at least 3 seconds about whether you need to give the variable public access. I'm not even talking about the SerializeField attribute. If you're not going to work and you make games only as an indie developer, then okay. But anyway you didn't have «code learning», you didn't learn how to code.
You got to all riled up about the dude leaving public variables, but I worked in a big tech company and you can't imagine how many big programmers (seniors, 15+ years xp) working in huge application projects just leave public variables left and right. It is a bad practice and doubles the workload sure. But it's not a mortal sin. Relax man, you sound stressed.
@@eloreneloreneloreneloreneloren Dude that was too harsh, relax. Even people with tons of experience sometimes leave public variables thinking it will be needed that way in the future, and just forget about them past the time. It's a bad practice but no one is going to die due to that, just more workload.
@@eloreneloreneloreneloreneloren Jesus Christ m8, no need to be so harsh. If you didn’t know about it then there’s no need to be so harsh. They aren’t showing an ego and they aren’t Being an ass about it so no need to be an ass
The best example I've come across as to why you should make fields private and use functions to access them is to think of it like a device such as a TV remote.
Do you need to know how a remote works in order to use it? Nope. As long as you have the buttons needed to perform its function, that's all that matters. In fact, if late at night a bunch of garden gnomes sneak into your house, and completely change the inner-workings of the remote and then leave - if the next time you use it and it still functions the same, you won't notice the difference.
In a similar manner, the public entities of a class are those "buttons", and other classes should use those without having to "know" how they are defined as long as the expected result is achieved. You should make it in a way such that you can change the way your class works without affecting code in other classes.
I did wonder about this when I started learning coding, never knew why until now. Thank you for the knowledge.
Hey Monkey,
this video should naturally continue with using a property for public reading but private writing and also you should check out the benefits of using scriptable objects as variables because it avoids dependencies and unnecessary errors. I admire what you do for the community! Cheers!
Events are also good for reducing dependencies but it becomes ever more important to have good documentation as you may not receive errors in the console when things are not working properly.
if you want to take it to another step, fields should NEVER be public. They should be exposed through properties or methods (just do a quick Google search on Properties vs public fields).
In C# you can create a public auto properties like this:
public float Speed { get; set; } //The naming convention for Properties is PascalCase
However in Unity, public properties will not be exposed in the Inspector, this is because a Property is literally just a layer of abstraction which includes a private backing field and two public methods, you can think of the property I declared above like this:
private float speed;
public void SetSpeed{float value} => speed = value;
public float GetSpeed() => return speed;
So in order to expose Properties to the inspector, you have to expose the backing field (which is normally hidden if you use auto properties) by using the [field: SerializeField] attribute, which basically tells the compiler to apply [SerializeField] attribute to the backing field of this property.
[field : SerializeField] public float Speed { get; set; }
What I also like about SerielizedField is that you can put further atributes to it, like Range() or Min(). That way you can clamp the value you can give in the editor.
You just blew my mind. Like, seriously, thank you. I have so many code in OnSerialize() that was there solely for the purpose of me not accidentally setting incorrect value to the variables...
This HAS TO become a series of clean code principles!
I just started learning C# for Unity specifically (about a week or so in). The series I've been watching has been great so far but I questioned this the second it was introduced. I absolutely asked myself, "Why would you make anything private ever?" Glad I got my answer, how serendipitous.
Got the megapack, very glad I could find a way to support your channel. You make much better tutorials than anyone else I've seen, and I direct aspiring Unity developers to you whenever I can. A big thanks for all the informative videos you've made, I will always be a silent supporter of your channel.
Many thanks! I hope you put those assets to good use!
Thanks dude! I'm exactly your target audience for this video and I appreciate it a lot
I'm glad you found the video and I'm glad you liked it! Thanks!
Amazing video! It'd be really cool if you turned this into a series about good coding principles for Unity :)
There is 2 things that I do to make a cleaner code : as you said in the video, I avoid as much as possible the public field, and when I make a public variable or a public function, I also add a comment to clarify the other classes/objects that use this variable/function.
I dont use unity but to just keep learning about everything makes me happy. I would love to see you make more videos about clean code. Very interesting and helpful
And here I was expecting you to talk about why going public (as Unity did some time ago) was a bad idea.
as a beginner I think learning serializefield is super important because of this exact reason. I find it very helpful when applying this to prefabs where you need a different variable in each situation.
This is quite a contentious topic.
Making everything private by default is what is thought in schools and is a generally accepted good practice.
Personally however, I find that non-public access is more trouble than it's worth. Every field, method, class and whatever I write is always public.
There are several reasons for this.
First: The language allows you to access private fields anyway, it's called reflection.
Second: You have to provide access to all your fields anyway (through methods/properties). You may think that you don't have to but if other people end up using your code then someone sometime is going to want to access that private field.
An example for unity: extending the animator. If you try this you will find that a lot of the fields are non-public, forcing you to use reflection.
Well, that's signs of bad coding practices.
Reflection for instance is a VERY costly operation that should be used only if you have no other choice, so if you find yourself using it more than a few times then the design of your logic is clearly wrong. Even more so if it used every frame.
Likewise, it's better to use protected abstract and virtual functions to allow people to write their custom logic via child class if they need to, because it provides even better flexibility at no cost.
@@oldcat1790 it's all fun and games when you call your code from your code. Using other people code, especially old code, especially in ways it was not made to be used makes it a different story. And yes, it is a smell, but it is a better approach to use at most protected so user can do something that is outside your assumptions. Else you need reflection or other such hacks to get what you want.
Thanks, as a self taught coder many of this basic concept of OOP alludes me (and i just follow them blindly because of "good practice"), and yes, you're the first one that explains the concept clearly
Code Monkey, thank you for keeping and not removing subtitles that are automatically generated by RUclips (even if the speech does not always match what is written in the subtitles). This allows me to translate them into my language (russian) and watch your videos.😜
I think part of the reason for beginnings to use public for everything is not yet knowing how to make Actions, Events, Accessors, Interfaces, and Constructors work. I would say I'm intermediate level and only just coming to grasp with these myself, but starting to internalize it and using them more and more.
I watched this video shortly after it came out, and after watching your video from yesterday (Difference between Transform & GameObject), I decided to check this out again since you mentioned it. I was curious if everything you said in this video had stuck, and I'm glad to say that it has!
I realise this is quite basic compared to most other concepts, but even a reminder on "simple" things goes a long way sometimes.
You're honestly a great teacher, Code Monkey. Thank you for all the amazing content and courses you've made.
Thanks! Yup the simple things are sometimes the most important
Thanks for the book recommendation! I saw this video while I was planning to learn unity, saw the book and decided to wait on watching the rest of the video till I read it. I just reached 6.2, where it talks about this, and so far, this book has taught me a lot! Thanks!
It's a great book, I'm glad you're learning a lot from it!
After remaking my project from scratch and use private most part of the time and not public as i used to do i had the same conclusion of this video, public variables are like those bikes with training wheels, they're great for complete begginers, but as time goes on and things get more complex, the training wheels most part of the time will only limit what experienced people can do instead of helping
That light mode IDE offends me
But i guess nobody cares 🤔
@@_GhostMiner it hurt my eyes
@@anonymous49125you want to be blind ?
All hail dark mode!
@@raoufbensalem3417 then don't watch. Not everyone likes dark mode
Thank you soo much, I just finished converting all my scripts to Private and Serialized Fields. Feels good having clean code :)
I recently picked up Code Complete 2 from your video with gamedevtv...I'm really enjoying it! Thank you
That's awesome! I hope it helps you just as much as it helped me!
Honestly I've struggled so much on this topic. Thank you for the guidance.
Pls more Clean Code practices! I love knowing this things
I haven't used public variables for almost 2 years. If I have to access the variable I create a property like public float Speed => speed; so they can access it but can't change it. for changing I use methods which is also still a rare case
Yup same thing here, I pretty much only use public for singletons and constants.
public static GameManager Instance { get; private set; }
I have made some games before but I still had some doubts regarding why something should be public or private. This is a great explanation, thank you very much!!!
Man you are speaking wisdoms in every video you make. Also when you said that the only limitation is the developer experience not Unity, that powerful words convinced me not to distract myself switching between Platforms. Thank you man🌹
One thing I like to do is have readonly accessors for my private fields if other classes need that information. So if we have
private float speed;
we would also have
public float Speed => speed;
so that we can read the speed value but not write it. Also => in this case is the short hand for
public float Speed { get { return speed; } }
You can also do this for functions too if it's a single line
The ominous "accidental modification". There is a cost in hiding access: it create lots of additional boilerplate code for public getters and setters. The cost is a longer time to scroll to the now longer sourcecode, with the programmer having less overview.
Unless the code is ment for others to use, such as in a library or module, adding lots "security" to the code can have a negative effect. It sufficient to make the interface to that module safe.
I'm having a feeling that the "accidental modification" part doesn't really change much with private variables and public functions.
If a script has a variable and a function for changing the variable, then how is it any less troublesome to change it from the function, rather than the variable itself?
If an error occurs anywhere, this means either the errors are coming from whichever function is accessing it, which was the exact same problem I was having before...
Or the problem is actually in the function I created, which means there's a new boilerplate code that I'll have to search as well.
Maybe the new function can also include some code that tells who is calling it, but this code might need to be written off in the end for performance issues.
The only place where I see are where the function happens to be both complex and general at the same time. For example, when my player dies, the player gameobject disappears along with some extra stuffs to show the player died. If I code all of it newly in every script that can kill me, then it's a lot of code to search for error correction. But if I do one death function to hadle all of it, I can easily check what caused it.
But for something so small as getting and setting values, this looks redundant to me.
Your videos give me feeling of a school and teachers teaching like in a session, especially the polls, keep it up
I like learning the "why" to certain aspects of coding.
I'm just starting out with C#, but not unfamiliar with some scripting. Regarding beginner's tutorials teaching to use Public fields: wouldn't it be better to teach the best practice early on? I know it could be a rabbithole of theory before practice, but as a new developer, it can be confusing to learn one way and then discover I should be doing it differently.
As I was told when learning piano, "practicing with the wrong technique will only make the learning harder in the long run."
However, maybe the important thing is to just jump in, without too much theory, since taking the initial plunge is often the most difficult.
I would love a video series on general architecture and design patterns and how they are used in game dev
Helpful video, keep it up!
I think a better way to manage accessibility is with namespacing. Obviously these should be used together for best results
Exactly. Code that is only used internally by one class can be private, there's no harm in doing so, and it will benefit you in the long-term. Unnecessarily publicizing everything will also make your properties explorer a lot more cluttered, since now if you want to edit a variable you're going to have to search through a lot of other variables.
I'd only publicize fields if I need to for debug purposes or to tweak values without recompiling every time I change it
Amazing video and very important idea
I wish we could see a series from this kind of videos
More Clean Code principles in Unity context! ❤️
C# allows you to define getters and setters that allows to control and access directly to public variables but read and writing will be performed thru getters and setters. That makes obsolete the must-to-be-private members with manually defined getters/setters.
Sure you can use properties instead of get/set functions, but you still need SerializseField to expose it in the editor
@@CodeMonkeyUnity the point is that using private properties has not advantages over public ones once you can define implicit hidden getters/setters to handle reads/writes to those public properties... no advantages in using privates and all problems and all overhead... I prefer to use private properties only for... really private things that are used in code internals, whose are usually not serializalbe and of course never exposed to the inspector (they are private!!! inspector is the more public-like-thing... making a private property visible for the inspector is like making it super-public).
also what you say from 6:00 - 6:40 is excellent!!!
This is literally the best explanation
I'm glad you liked it, thanks!
Thank you for this video, you confirmed what I have thought since a long time now. I would be very interested to see you dive deeper into this topic with getter and setter, or juste using function, buff and debuff ... Very good video for an important thing when it comes to make an ambitious game !
If you want to learn more about clean code I can highly recommend the book Code Complete 2
And I just recently released my latest course which is heavily focused on writing good clean code to take your skills to the next level ruclips.net/video/QDr_pjzedv0/видео.html
very good tutorial, i was always wondering why you make everything serialize field. this explains it very good.
I personally prefer to keep things as protected rather than private because it's pretty much the same as private except it makes code written more expandable later on without changing anything.
Pleaseeeee keep posting videos about "Clean Code" in Unity, I'm very interested about clean code, Thank youuu!
Great explanation process! I do try to avoid public variables and only using for Game Objects or Transform. You should also do an episode on public static variables. I try as much as I can to stay away from static and rather do properties or pass reference.
@@EvitoCruor You can still use the public static classes for example I will use them for an inventory class. The issue comes when you are getting an error when changing a public static variable and forget where the variable and change is coming from. Most of my games have 60 or more scripts : / better than doing one long script
Thank you! Finally! So many tutorials just toss about the public variables and it's very disappointing. SerializedField is also good for debugging as you can monitor the variable's value in the inspector in real time.
really cool video,
I always had the doubt of how to improve the code and not make everything public, I had heard that it was wrong to use public variables and now I understand why, thank you!
Your tutorials are amazing. Thank you.
This is nice! I do it by default, even when I didn't knew why, I really don't like when i bump into some experienced programmer that says, we'll fix it later (making unnecessary public variables for testing) which end up being part of the code and left as public...
Very good tip, imma use it from now on!
great video, thank you! I also like that this way the auto completion stays nice and clean.
I used to just shrug it off and do it my way, with everything public. Once I got a big enough project, I realized a few of the reasons we shouldn't make everything public. Now, I actually try to anticipate how exposed it'll need to be, and work from private to public.
I saw the thumb and thought that it was gonna be a video about LIFE lol, no problem though, keep it up
btw, that public variable you made called `speed` cant be used by other scripts THAT easily. You have to call the script in order to call it's public variables so Idky people act like its the other way around.
Awesome vid! Can you make more clean code videos?
Useful for beginners ! But following carefully any of your videos related to the code, you can instantly learn how to write clean code )))
Great advice. Thank you so much
I enjoyed and learned so much from your videos, Code Monkey! I went ahead and bought your course on Udemy. Thank you!
Thanks! I hope you enjoy the course!
Nice step-by-step OO lecture
Great video!!! It's really helpful.
This is great advice for beginners moving up to the intermediate level, but I have found that, in moving from the intermediate to advanced level, making things public is almost universally better--though the reasons are nuanced, address long-range issues, and assume some things.
The problem with private variables arises when one transitions from writing game logic to tool logic (which is then assembled into game mechanics by juniors or non-programmers). At that point, the logic "only make something public if it has a clear reason to be public" breaks down because you can't possibly know the full range of use-cases in advance and so to lock something down imposes a permanent design limitation based on a lack of imagination. As a specific example, when working with Mecanim, one must maintain a code-based state machine to control characters with animation in addition to the animator state machine and keep both in sync with each other (or work around the system entirely with animator.Play("magicString")...all because someone at Unity couldn't think of a reason to access animation states other than the one currently playing and made that information private.
This may sound like an edge case, but over the years, I have lost weeks if not months worth of development time working around tools that have made things private that I needed to access for some reason, and 0.0 seconds debugging problems that arose because something was public that should have been private. Further, in my own programming, I have recently been leaning heavily on a nested composition pattern, where every piece of code has the potential to become a building block for code that operates on a higher level of abstraction, and in that context it is often useful to change settings externally via OnValidate.
Another, more nuisance-level problem is what I call "fake encapsulation". For example, this disturbingly-common nonsense:
private myVariable;
public MyVariable { get => myVariable; set => myVariable = value; }
Assuming the above is not to complete an interface, the above pattern adds negative value. In addition to wasting space, it also creates the illusion that myVariable is protected from access from the outside, when in reality it does literally nothing other than require using a capital 'M' to access it.
Now, I am making a couple of assumptions that mitigate the benefits of private variables/methods. First, I am assuming one has an IDE with right-click -> find all instances. Second, I am assuming that every...single...time one modifies a variable, especially one in a different script, one does so with a knowledge of the impact of changing that variable and the alternative ways of accomplishing the same goal (as opposed to just looking for something quick that "works"). I take it as an axiom that if new code breaks something, it is ALWAYS the fault of the new, accessing code, and NEVER the fault of the old code not putting up sufficient guard rails. And if the goal is communicating intent, that's what comments are for. By analogy, if a neighbor breaks into my house and steals my computer, the neighbor is to blame for the loss, not me for having insufficient security.
Granted, being mindful about how variables are set is certainly good practice. For example, calling a Damage(int value) function instead of directly decreasing health is probably a good idea. This, however, is not for the sake of "protecting" the health state, but for the sake of readability, since damage is the concept being implemented and it just happens to result in decreasing health (possibly among other things).
Thank you. #vindicated
Calling a Damage(int value) function is not for the sake of "protecting" the health state, but for the sake of keeping an eye on health changes. During debugging you can easily add debug.log into such function, unlike direct changes.
As I said, treating Damage() as a process that happens to involve decreasing health rather than directly accessing the variable makes sense.
And yes, having the potential to easily add debugging logic is one benefit of this process framing. That said, in a context where debugging is the only additional consideration--that is, when it actually makes sense to modify the variable directly because that is a better analogy for what is happening than a process--you could do so with setter logic.
In any case, my point stands: whenever anyone actually argues that variables should not be public, the stated reason is pretty much always for the sake of "protecting" state, I'm inclined to take them at their word, and I don't consider this a valid reason.
Great video! A similar one could be the implications of singletons as I feel like they are something I used to abuse alot in the early days too (and still do when im lazy.)
Great vid thanks :)
You can also make a variable with a public get and private set. That way other classes can check the value of the variable but it cannot be modified
That would be a property, not a variable, and yes properties can indeed be used for validation and limiting get/set
Thank you for your wide verity types of videos. Your Chanel is the best for learning unity tips and tricks
I just wanted to know if you have a plan doing a series of videos to cover making textures from beginner to pro as they can be used every where?
The title sounds like privacy informative video
That's is .POG.
Interesting but I found making everything public helped me in my coding a lot. I just have a strict rule never to update a public variable in more then one spot and all the code can read it but only updated in one place, so if other things needed to influence it then create new variable for that and still update the main variable in the one place with those adjustments if needed. I also of course use longer and more detailed variable names to reduce conflicts and also a full list of all used variables in a table I can check is not already used elsewhere....not hard and solved a lot of conflict problems that way. The full variable table was good to also sort between what needs to be saved in the game save state and what is not needed.
I also have tended towards functional programming which allows local variables that are not global by default anyway (unless I want them to) so also helps a lot in avoiding conflicts.
im not even in gamedev and this is pretty useful
Hey Code Monkey, have you written unit tests for your games?
Do you have plans on covering that as a tut perhaps?
I don't normally do unit tests for my games since I have to work insanely fast in order to find success with those games, but I am constantly trying to write code that could be testable.
So I'm constantly thinking about how to minimize dependencies and make every script as standalone as possible.
Unity does have a bunch of Unit Testing tools which I've never used but I'd love to research them when I have the time.
I'm of the mind that you should tend toward protected rather than private. Nothing worse then inheriting a class and needing to change one small thing but you can't because developers are obsessed with making things private. Then you have to duplicate code to achieve what you want because you're not allowed to edit the original source.
This happens to me more often than is reasonable contracting for epic.
Hello,
Is there any difference between
float speed;
vs
private float speed;
should I always use private?
Some compilers default to private, others to protected.
On a class hiding it might make it private, on an interface it will make it public.
So it's always best to be clear and specify exactly what accessibility you want.
@@CodeMonkeyUnity Thanks for the reply. What is default in unity?
another tip is if you want a field to be public but you DONT want to add it to the growing mess on the editor, make it internal.
For that you can also use the attribute [HideInInspector]
You should not use public fields at all. Use methods and properties (properties are actually methods) to change them (encapsulation)
Just asking : How did you started your game development career? I mean what kind of game engine you used and programming language as well. Just want to know, to have a basic idea. Iam currently having a hard time in using unity. Specially at coding but I love to code and want to do so. Your channel helps a lot to fix them.
Thanks for your support through videos. ❤️
I covered my game dev journey here ruclips.net/video/0zscPf_U1VY/видео.html
Basically I started making IRC scripts, then moved onto Flash and finally when I wanted to make PC games I found Unity and I've been using it ever since.
2 questions I have about this:
1 - Would this mean having all variables private and setting them trough public methods?
2 - Using this logic, can I still use {public get; private set;}?
I say this because having all variables private would make hard to get them on other scripts, so I can use my second question to get them, or use a public method to do so?
Yes exactly and yes you can use properties as accessors. Personally I prefer get() set() functions but properties can work as well, the point is to be able to add some extra logic so you're not accessing the variable directly.
1. what is the difference between a private variable and one with no definition?
2. should you use the hideInInspector atribute when you dont want to modify the variable in the inspector?
1. variables in C# are private by default so you don't need to explictly state private but you should for readability.
2. HideInInspector is only really useful if you aren't using serialized fields. If you don't want it to be in the inspector just use private. I've never found the need for HideInInpector when using clean code principles.
@@Wobling A quick note on your 1st point:
- This is true in a class or a struct: members are private unless you explicitly state otherwise.
- In an interface or a namespace (or even outside of any namespace), members are public by default.
As you mentionned, it's a good practice to explicitly write the accessibility level, even if it becomes redundant with the default behavior.
@@GiraPrimal This is correct, thanks for the addition :)
How would you go about changing a private variable from another script? Like the SetSpeed() you mentioned? Won't public functions make your code less scaleable (I could be misunderstanding something)?
Yes exactly, "less scalable" can also be described as "less accessible" which is exactly the point, you want to limit access as much as possible to limit how many possible things can go wrong. It's much easier to find references of all SetSpeed(); function calls than all read/write direct access to the variable itself.
You should never expose a Field public. If you want to change it, use Methods or Properties. The official C# documentation says: Never expose the inner workings of a class.
except cases when you need to work through the pointer with some of pointer's object's methods so you make it public. Because if you not, you need to make methods to call methods which change private fields
oh my god, no. that's some dumb, old timey, Java verbose nonsense. this video is a disservice to actually writing clean code. yes, you shouldn't expose the inner workings of a class. which includes the inspector! if something is visible in the inspector, then it should be visible from other classes as well! this is literally what every built-in Unity component does!!
@@henrycgs I mean, unity can compile them as just private since you don't need (and not really able) to use the inspector in the build?
@@c1oudsky I don't know what you mean. Compiled code doesn't have encapsulation as far as I know.
So many tutorials use Public variables and it's something that has always annoyed me. Unless you require external access, just make everything private. And a lot of the time if you require external access you can make use of get/set and have much greater control over access (eg make getting the variable public but setting it private etc). And if you need access to private variables via Unity then use [Serializefield] attribute.
*Me looking at my coworkers that makes ALL variables public*
I thought you meant open source by public at first and it took me a whole minute to realize that "public" meant the access modifier.
This is good to know as a beginner programmer :)
I think the real problem is not that field is public but the way those systems are constructed to interact with one each other is inherently hectic. making the variables private doesn't solve nor improve how the system would interact with each other. If anything making things blindly private has the potential to add more complexity to the system since you're adding layers of abstraction to your data fields. Now should you have a bug involving that data field, instead of just looking at who accessing the field directly, you gotta sifting through a bunch of different methods to find the problem.
yes! a private var with a public accessor function is more difficult to debug and scales worse than a simple public var.
i justt started learning with Unity. after this video im wondering why i would ever use the public version now instead of a Serializedfield?
should i avoid this completly or are there some circumstances where the public version still makes more sense to use?
thanks for the great videos btw.! im learning alot from you!
what's the difference between modifying public variable from other function and modifying private variable with its public function from other function
I actually start off making all of my variables private but, then change them if they NEED to be accessed from other classes.
So in my case, i'm trying to make a racing game but have two separate scripts that handle the acceleration and steering of the car and I have code attached to this that decreases the speed of the car by a certain amount when turning. I do this by making a variable for the acceleration script and then modifying the speed variable whenever the player turns (the speed variable itself is public since I can't get access otherwise). I'm still relatively new with programming even though i've been doing it on and off for the past few years so this may seem like a dumb question, but is there a more efficient way that I should be doing this instead of making the speed variable public?
beginner here, thank you!
A must watch vídeo
Great video...cool thing (coming from an Game Engineering Student second year)
Now i have knowledge. Bye gotta go and change every variable to sterelized private
Make more videos like this please.
The problem that I face while keeping as much as possible private is that I just dont understand on how to reference something private in one script from another script. It sometimes not work for me even if I copy directly from someone else's scripts
Tnx 🌷🙏 really good,
love your videos bro. some day soon when i get a job in the field i'll donate. thank you
Best of luck in your learning journey!