public or private
what function does add "public" or "private" and so on in front of "Start"/"Update"`````?
Answer by _Petroz · Jan 06, 2011 at 03:24 AM
There is no reason to make Start or Update or any other MonoBehaviour functions public. They will be called by Unity regardless so it's best to make them private.
Making it public would allow you to call it yourself from outside the class which probably isn't a good idea.
Answer by Loius · Nov 13, 2010 at 03:55 AM
Most beginner programming tutorials will cover this.
Public means that anything anywhere has direct access to whatever it is.
Private means only members of this class (and by extension, its children) have access to it.
Protected means only this class, its friends, and its children have access.
class Awesome {
public bool ladeda;
private function Foo() {}
protected function Foobar() {}
}
Any object can store a reference to an Awesome (that is, var awesome : Awesome or public Awesome awesome) and access its "ladeda" variable. They cannot access its function Foo, though. And they can only access Foobar if they are declared as friends (I"m not sure how to create friendships in C#/Unityscript, or if it's even possible).
If you then have a
class MoreAwesome extends Awesome {
public function Do() {}
private bool no;
protected bool yes;
}
MoreAwesome objects will be able to access the Awesome functions Foobar and Foo, as well as the private boo lean. Awesome objects won't be able to access MoreAwesome's no (I'm not sure about the yes.)
Basically public means visible to all classes and private means visible to only this class.
Good answer.
FYI there is no such thing as 'friend' in C# or Javascript, also in C++ friends have private access not just protected.
I'm sorry but this is incorrect. $$anonymous$$oreAwesome (being a child of Awesome) would not have access to private function such as "Foo". According to inheritances, "your children cannot touch your privates, but your friends can". But you are correct that Awesome would not be able to alter $$anonymous$$oreAwesome's "no" because "you cannot touch your child's privates." Additionally "children can touch parents protected, but parents cannot touch child's protected".
This explains how public and private work in C# generally, but it doesn't explain how they specifically work in a Unity context, where an experienced C# programmer new to Unity would expect making the methods private to mean they can't be called by the Unity engine either.
(Un-burrying old post) I'm exactly in that case, developping C# for a living, and the concept of "friendship" is bugging me. As well as methods being inherited from say $$anonymous$$onoBehavior, not being overriden but just declared as private. When starting Unity I was expecting more proximity to C# grammar and syntax. But nevertheless, this post answered my question.
Answer by sukul · Dec 29, 2014 at 04:01 PM
actually in public
you can edit the value from the inspector if you wanna build a variable which uses your control avoid it in private
the variable remains inside theprogram
you cannot edit it unless opened the script
use this when building a variable which uses your control to do actions
hope this helps
Public does expose variables in the inspector. But so does tagging a variable with [SerialiseField]
. $$anonymous$$arking it this way is safer then public. Public variables should only be used if you want to allow access from other scripts.
Answer by atrajano · Jun 17, 2017 at 06:10 PM
One note...
Classes and structs that are declared directly within a namespace (in other words, that are not nested within other classes or structs) can be either public or internal. Internal is the default if no access modifier is specified.
When I go through the tutorials I change them to private
explicitly. It also allows me to flag that method/member as something I have read already and understood. I also convert the variables to var
for the same reason.
I'm sorry, but using var
is a very bad coding practice and you shouldn't do it, no matter the reason. You are lucky enough to be using a typed language, use the types! They are there for many reasons, and help you prevent many mistakes.
the usage var
is for anonymous types, which you can't declare without it, and can greatly improve code readability when dealing with coplicated types (Class>) as long as the variable name is clear enough for you and your collegues. It shouldn't be banned because you can't see the type direcly, just be careful not to obfuscate your code with it. $$anonymous$$any strong application (well designed ones) and top developpers uses this. It exists for a reason, it's up to you to use it well.
Fine. Use it well. The suggestion in this reply, however, definitely isn't an example of careful and well-thought use.