🌍 FREE C# Beginner Complete Course! kzfaq.info/get/bejne/priVhZmLntivXaM.html 🔴 Watch my Complete FREE Game Dev Course! 🌍 kzfaq.info/get/bejne/d9N3hqh5nLfHdJs.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.

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.

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!

I did wonder about this when I started learning coding, never knew why until now. Thank you for the knowledge.

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.

Amazing video! It'd be really cool if you turned this into a series about good coding principles for Unity :)

That light mode IDE offends me

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.

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.

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.

Code Monkey, thank you for keeping and not removing subtitles that are automatically generated by KZfaq (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 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

This HAS TO become a series of clean code principles!

I recently picked up Code Complete 2 from your video with gamedevtv...I'm really enjoying it! Thank you

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.

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🌹

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.

Thanks dude! I'm exactly your target audience for this video and I appreciate it a lot

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!

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.

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

Thank you soo much, I just finished converting all my scripts to Private and Serialized Fields. Feels good having clean code :)

I like learning the "why" to certain aspects of coding.

Code Complete is the BEST book I've ever read.

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.

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

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 !

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).

Honestly I've struggled so much on this topic. Thank you for the guidance.

Pls more Clean Code practices! I love knowing this things

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.

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.

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; }

And here I was expecting you to talk about why going public (as Unity did some time ago) was a bad idea.

This is literally the best explanation

very good tutorial, i was always wondering why you make everything serialize field. this explains it very good.

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 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!!!

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

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.

I enjoyed and learned so much from your videos, Code Monkey! I went ahead and bought your course on Udemy. Thank you!

Pleaseeeee keep posting videos about "Clean Code" in Unity, I'm very interested about clean code, Thank youuu!

Your videos give me feeling of a school and teachers teaching like in a session, especially the polls, keep it up

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.

Awesome vid! Can you make more clean code videos?

I would love a video series on general architecture and design patterns and how they are used in game dev

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!

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.

More Clean Code principles in Unity context! ❤️

Amazing video and very important idea I wish we could see a series from this kind of videos

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.

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.)

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...

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.

I think a better way to manage accessibility is with namespacing. Obviously these should be used together for best results

also what you say from 6:00 - 6:40 is excellent!!!

Nice step-by-step OO lecture

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.

great video, thank you! I also like that this way the auto completion stays nice and clean.

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.

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

Hello, Is there any difference between float speed; vs private float speed; should I always use private?

Great video!!! It's really helpful.

Helpful video, keep it up!

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?

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.

Your tutorials are amazing. Thank you.

Great advice. Thank you so much

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.

Useful for beginners ! But following carefully any of your videos related to the code, you can instantly learn how to write clean code )))

Great vid thanks :)

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

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?

love your videos bro. some day soon when i get a job in the field i'll donate. thank you

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.

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)?

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?

Hi, I am following your videos for a while now. I have a friend who is deaf and watching your videos, i sometimes explain him what are you talking about and what are you saying(auto subtitles are messy). So if you open subtitle adding feature i will be happy to help adding subtitles. Thanks in advance. Keep up good work :)

Very good tip, imma use it from now on!

Now i have knowledge. Bye gotta go and change every variable to sterelized private

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!

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. ❤️

Well explained. Why did you change the recommended book? It seems to me that in your video on how to become a developer, you recommend "Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)" ?

beginner here, thank you!

what's the difference between modifying public variable from other function and modifying private variable with its public function from other function

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.

Never seen your channel before and thought you were gonna be talking against open sourcing applications lol

Make more videos like this please.

You should not use public fields at all. Use methods and properties (properties are actually methods) to change them (encapsulation)

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

Is there any adventage of serialisefield over protected? Edit: I realised this should not even be a question since they work mostly differently

Damn yes yes yes I started doing this a while back and I maybe use a public variable like once a week

A must watch vídeo

Great video! Although in my experience I think its a good idea to first start out making variables public. Because the reality is, is that you will not be sure what you want to be private or public just yet. And then when you are 100% sure on which ones need to be private, change them to private. So why not do it in reverse? Start private? Then set public if needed? Because then you don't have to set Serialize Field EVERY variable. It's a better workflow if you are experimenting on a game, to just code free spirited at first and then clean your code as you go. Just my 2 cents.

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?