What do the following symbols mean in the Unity script?

exclamation / !
equal / =
two equals / ==
point / transform.position
comma / ,
semicolon / ;

 

These are all pretty standard and basic programming language symbols (and most are common among modern programming languages), and I recommend you follow the beginner-level Unity scripting tutorials. I suspect that if you don't know that = is an assignment operator, then you probably also don't know what an assignment operator is. Therefore, a quick answer may be of limited use, and a longer answer is basically just a beginner-level coding tutorial.

But for the sake of quick reference:
! is "not".
= is an assignment operator.
== is a comparison - it checks to see if both sides are the same
. is, in this context, an operator that "digs into" an object. In this case, it finds the "position" property of the object named "transform".
, is generally used to separate parameters being sent into a function call
; ends a C# statement

 

I'd recommend following a basic C# tutorial, as none of these symbols are Unity specific. They are just the basics of industry standard C# syntax.

 

If you want the basics of C#... personally I like to go to the source from the people who create it. Microsoft, or specifically MSDN:
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/

Pretty much all the links on that page get into the fundamentals of the language (like the operators/symbols you just listed)

And MSDN in general is probably the best tool for language specific needs. I urge you when googling/searching, don't include "unity" in your search, but rather look more generally at C# results. That is unless you need to know a specific Unity thing (like the Unity API [once you know what an API is), editor, or behaviour in general).

 

Eh....I'm not sure I agree. There are certain things which if searched this way would produce search results that are not only unhelpful, but may even make it harder to grasp the concept as far as it's relevant to Unity. IEnumerators/coroutines come to mind, for example. Also, non-Unity discussions of null comparisons might make someone more confused about how "!= null" means to check if an object has been destroyed, thanks to Unity's overridden null comparison. Constructors are also treated differently in Unity than in other C# scenarios. And so on.

And it's not likely that someone who needs to know what those things are will know whether it's best to search for a Unity-specific explanation or not.

And just in general, having examples that are more relevant to the environment you're actually working in will make those examples much easier to process and understand. If you don't find helpful Unity-specific examples/explanations then yes, absolutely go check out general C#; but I recommend starting with Unity and branching off from there.

 

True, but I could argue that searching with Unity only in mind could also produce results that make it hard to grasp the concepts as far as programming goes. Instead sticking you in a "unity only" box.

But also often limits the perspective of what's going on development wise. I often catch people (OP even did it) confusing things about the C# language as if it's a "unity thing" and can't find any results. Because they don't realize it's a C# thing.

You of course argue that if you don't find results, then broaden to C# in general.

I personally prefer the other direction. I like a broad introduction followed by a specific example. Rather than a specific example only followed by a broadened view if I go looking for it and that's only if I knew that there was a broader perspective in the first place.

Similar to how you usually learn things in books and class anyways. They start with a broad introduction and than narrow in as you learn, usually leaving the real-world specific usage towards the ladder parts of the lesson.

Take like serialization... should I learn serialization specific to Unity or specific to programming in general? If I learn it specific to Unity I may find myself thinking this is the only way it works, or I might confuse the serialization of my scenes with the serialization of my save files. It will definitely get me on my way in getting something working in my game potentially faster, but at the cost of potentially not knowing what it is I'm actually doing. Resulting in a magic black box that I only prod/poke until it works. (a thing I see in my professional work all the time with my team members)

But you know that's all personal preference. My suggestion was that, my suggestion.

(of course one could argue why not suggest starting above C# then... and honestly... I would)

 

Thanks, I think now I understand a little better about scripts and their symbols;