It may seem odd, even rude, when you post for help with a technical problem on the forums, and then get replies that criticize your spelling, capitalization, and so on. What does it matter? Why do they care? It still works, right?
A big part of coding is, of course, creating code that works. However, another big part of coding is making your code readable - able to be understood at a glance. When you're using well-established classes and functions - say, GameObject and MonoBehaviour - this is pretty straightforward. But if you're looking at a single script that references other scripts - or moreso when you just look at one function from a class - this becomes a bit of a chore, if not outright unknowable.
Essentially, when any other person looks at your code, the first step is going to be to figure out what exactly is happening in the code. Writing code that is clearly and consistently labeled and stylized makes it much easier to work that out quickly, and becomes a huge timesaver.
"But StarManta," you say, "This is just a personal project. I'm the only one working on this, and I know what I mean without you telling me how to write it!" Well, for one, you probably got linked to this article after posting some code on the forums, and the people helping you are also reading your code. For two, it's better to develop good habits early on, because most likely, you'll eventually want to collaborate on something.
But more importantly is this life lesson: As a programmer, you are never working alone: You are always collaborating with your future self. If this doesn't make sense to you, and you just started coding, I can't offer much more advice to you than, "Give it time." At some point, you're going to open code and wonder what that idiot was thinking when he wrote this, only to realize it was, in fact, you. All of the thinking that goes into a given piece of code is fresh in your mind now, but after a little while, it'll all go away. And when it does, you'll curse yourself for using "text1" and "text2" as your variable names.
One of the more common coding style criticisms - and one that's not intuitive for many rookie coders - is when to capitalize names of things. Because scripts will still compile and work just fine no matter how you capitalize things, and 90% of your job as an inexperienced program is figuring out how to fix compiler errors, this problem is often not even given a thought.
Consider the following code for a waypoint, which will lead to the next waypoint in the series:
public class waypoint : MonoBehaviour {
public waypoint NextWaypoint;
}
If I could see you through the monitor, I would be able to instantly gauge your level of experience when you look at this code: the more squinty and perturbed you look, the more experienced you are, at least until you get to the point where you just find code like this tedious and sort of roll your eyes.
The standard practice for capitalization in much of C# (particularly in Unity) is this: CapitalLetters for class names and methods, camelCase for variable names. This is used liberally throughout Unity's own source code, which is why you can know instantly that "transform" refers to the object you're on right now, and "Transform" refers to the class itself.
In order to see the problems with breaking from this standard, put yourself in the shoes of someone helping someone else on the forum. Let's suppose that the person you're helping has the class as written above, and is adding a function to get the distance to the next waypoint. He posts the following code, asking why it doesn't work:
public float DistanceToNextWaypoint() {
return Vector3.Distance(waypoint.transform.position, NextWaypoint.transform.position);
}
On its own, there appears to be very little wrong with this code, but if you have seen the class above, the issue is obvious: "waypoint" is the class, and the person clearly wanted just "this" or to simply skip the first part entirely.
Now consider this: When programming, you will often look at snippets of code without context. Even when you're looking at the actual script file. As scripts grow larger, it will eventually become prohibitively cumbersome to look over the entire script to figure out whether a particular name refers to a class, a function, or a variable. And even long before your scripts reach that size, being able to read 1 line and know what things are compared to needing to read the entire script to know what things are is a HUGe time saver.
In truth, getting capitalization to match with the accepted standards really just a subclass of...
In high school programming classes, I was taught that a good programmer would write lots of comments. Every function should be described, its purpose should be outlined, maybe even the pseudocode of the function would be included as a comment.
Well, times have changed, probably because eventually someone realized that no one is ever going to write that many comments no matter hard we try to make them. But from the ashes of that standard comes the new standard: Write your code clearly enough so that it doesn't need to be commented, or at least, so that it rarely needs to be commented.
Again, this is particularly useful when viewing snippets of code in isolation. In fact, imagine that every line is viewed in isolation; does that line make sense?