By default all methods are private. That means that when declaring a new method there is no need in adding “private”. Play mode starts well in both cases.
Then why in some tutorials teachers do add this word?
like this:
private void OnTriggerEnter2D(Collider2D collision)
As you gathered, it’s optional. It’s really a matter of your preference whether you want to include it or not. I come from a Java background where private is not the default, so it can help me sometimes if private is there always so I remember that things are actually private. It can also help to teach new programmers what the access modifiers mean.
Some other reasons:
Saying “private” makes it 100% clear that you are doing that on purpose (rather than because you forgot to say something else).
If you don’t say “private”, the reader needs to know/remember the context in order to figure out it’s private. If this were an interface definition rather than a class definition, then everything would be public instead. If you were writing in some language other than C#, the defaults might be different. If you say “private” explicitly, the reader doesn’t need to try to reason it out.
It my personal opinion, when you’ve got public and private functions side-by-side, omitting “private” is mildly aesthetically displeasing because it makes the source code look unbalanced.
It can also be mandated by team coding standards. Often programmers bring home team standards for personal projects out of habit.
Some other people like like the look - just preference. Personally it looks weird to me if private isn’t written there, so I usually write it. But I’m someone who also writes the below for personal readability as well, even though it puts me at risk of being tarred and feathered here.
if (myBool == false)
@Joe-Censored
for me it’s only about the extra step at reaching the same conclusion, but I have nothing against the added clarity. (i.e. just tar will be enough.)
Mainly for the sake of completeness, and because it’s not always assumed, in different contexts, or other languages.
I tend to avoid typing it only if it is sufficiently clear from the context. I.e. in a block of similarly private fields. I also additionally make a difference in how I treat variable names based on their accessibility. PascalCase for public/internal, camelCase for private/protected. I treat the methods the same, though MSDN recommends PascalCase for all methods, I don’t like that, I like seeing anything private as slightly messy, slightly bumpy, slightly more cryptic, and well … like how any mechanism should look from the inside.
BUT it must be always visible if it’s important (so no code folding, that’s something I don’t do) and very readable, and I like to revisit the same code, after a couple of days, to see it with a different set of eyes, while the thing is still fresh in my mind.
Class fields always begin with an underscore unless public, properties make little sense to ever be camelCase because they’re usually always public. There are some exceptions to this style, but these are always based on obvious practicalities. Exceptions are used whenever enforcing my usual style would only hurt readability. For example, underscores are really only useful if you’re accessing the fields from INSIDE the object, so you can just glance over a method and tell if it’s pure or not. Outside of that usage pattern, they really add nothing of value.
So this is how this works. You try to bring your code closer to what’s your normal cognitive expectation, so that your brain can process more information per unit of time, without having to spend energy translating meaningless notation. Any style that lets you focus on your tasks in a manner that doesn’t occlude glaring errors to your future self or anyone else who might have to look at your code, is a good style. Now whether you include private keyword or not, that’s highly subjective, can be made self-explanatory, and likely is just a matter of habit.
It is optional for a reason, but I’d recommend consistency throughout the project.