Unity are best buddies with Microsoft now and doing C# tutorials with them for Unity.
But I note that they still use their variations on naming syntax in their own UnityEngine code which Visual Studio would highlight by default (following microsoft’s naming syntax suggestions).
Unity’s properties for instance have always started lowercase but usually variables only start lowercase, properties uppercase.
Not sure I have a question on changing this because for Unity to change it at this point would be project breaking!
But what to do in future in their new APIs?
We actually are using a style much closer to the standard .NET naming conventions in the new DOTS code.
As you say, we’re not going to change the older UnityEngine stuff because it would be a massive breaking change, and when we’re adding code in UnityEngine it is better to be consistent with what’s already there.
Just wanna chime in and say I would rather have convention breaking code that doesnt break existing projects, than have unity shift all the old code to proper conventions and in the process ruin a lot of peoples projects + probably lose a big chunk of their userbase.
Most of us are very used to the conventions in unity c# as we have been using it the same way for years, so its great DOTS is going to follow closer but @superpig imo has the right attitude about the issue in terms of reducing harm by reducing breaking changes
Conventions are conventions, and rules are rules. How you name things is all about conventions, and have nothing to do with rules. When you’ve worked in as many languages and systems and generations of coding standards as I have, you stop caring about the “vi vs emacs” religious arguments, the @Simonyi Hungarian Notation vs Camel Case" nomenclature, and whether you use tabs or spaces. I have my preferences and I like to keep consistent with my own style, but I really don’t care too much about how Unity names things as long as it’s in the documentation.
This, and naming conventions are realistically the least of our problems. Checking if objects are null will be more confusing to someone just getting started than inconsistent naming conventions.
There is a really good reason for this. The two different standards are attempting to solve two different types of problems.
In Unity performance is paramount. That means you don’t use properties unless you have to. In a lot of cases, you don’t discover you want to use a property till half way into the project. In this case, its useful to have fields and properties using identical naming, so that you can swap them around without refactoring.
In Microsoft the assumption is security and maintainability are paramount, which means you always use properties. You never need to change a field to a property, because you always start with properties to begin with. In this case its useful to have a different naming convention.
Most of the time performance is not paramount. In the particular case being discussed, of properties vs. fields, there is unlikely to be any measurable difference unless something is being accessed many, many times per frame. It’s a micro-optimisation that’s likely to have costs elsewhere.
In the vast majority of cases I’d stick using fields over properties in the “premature optimisation” bucket. If it’s going to make a difference then you really ought to be thinking from a data structures and algorithms design perspective first.
This approach isn’t applied consistently within Unity in the context of performance anyway. For instance, unless you were already pretty familiar with Unity, who would guess that this…
for (int i = 0; i < mesh.vertices.length; i++)
{
SomethingTriviallySimple(mesh.vertices[i]);
}
… could in fact be cripplingly expensive*?
I would propose naming along the lines of mesh.ReadVertices(), as opposed to hiding an interop call which copies a potentially large data structure behind a thing that looks like a variable.
It could also be even less obvious, as Mesh objects aren’t always called “mesh” in our code.
Style conventions among other things make code easier to reason about. Anything that makes it so you don’t have to stop and think is good. A mix in the same codebase of class fields starting with upper and lower case for instance can have you scrolling all around to discover the scope of stuff. That to me is super annoying.
What’s more annoying is people that can’t just go with the flow, try to carry over styles from other ecosystems into a new one because it’s what they are comfortable with. I actually worked with one OCD individual back in the day on a ruby project who used braces, he literally put commented braces into the code because he couldn’t adjust.
Except using fields over properties is less key strokes. If anything using properties by default can be described as “premature architecture”. You are setting up a system before you know if you are actually going to use it.
Agreed. This one is particularly horrible.
Although I would argue this is a different problem. Here the rule broken is “don’t put performance heavy stuff in a property”. Not “use different style conventions for fields vs properties”. Were the property instead called mesh.Verticies, one would still assume a trivial call time.
I was speaking purely in the context of picking one over the other for performance reasons. I’m advocating against making the selection based on performance, as opposed to any particular choice over another. Yes, there are definitely other factors which I would also take into account.
That said, keystroke count isn’t one of them. Despite being a somewhat average typist this has never been the bottleneck in my work.
Now if only Unity would serialize those things properly…
Valid.
I guess my key point is that conceptually properties pretend to be fields. So it makes sense to use a naming convention that lets you switch between the two without having to refactor any of the consuming code. The typical unity convention of using camel case for both properties and fields does this.
The Microsoft convention of using different cases doesn’t do this. It means if I ever want to switch between a field and a property, I have to refactor consuming code. Which is bad. Especially if there is more then one dev working on a project.
Its not so much that I always want to use fields or properties. Its that I want to have a choice to be able to switch between them at will throughout the project. And the Microsoft standard only makes sense if you restrict yourself to always using properties.
Do keep in mind that our tools can generally make the refactoring bit trivially simple if that’s what we want.
Also, when there are other people involved and/or the thing you’re changing is used in a lot of spots, it’s typically a good idea to communicate and check that stuff anyway. While it’s not practical in all scenarios, I have more than once deliberately changed the name of a thing, even temporarily, so that the compiler forced me to check every single place it was used.
I think that’s entirely the point. And, notwithstanding that I don’t like properties in the first place*, it’s a default position I tend to agree with.
They allow obfuscation in exactly the manner being discussed here all for the sake of allowing code to be a bit “neater” by some arbitrary standard. I don’t see why it’s important to be able to write “X = 3” instead of “SetX(3)”.
Less clutter in any location that the properties have to be listed (ie IntelliSense, documentation, etc). Both vertically (you can list more properties than you can get/set methods) and horizontally (I feel like it’s easier to notice the property when you’re not having to mentally filter through superfluous words).
