Unity uses camel-case (initial lower case letter) for properties across its entire API’s, yet JobHandle.IsCompleted uses pascal-case (initial upper case letter).
Is this considered an issue? Is this a known issue?
For completely new API’s we are using the .NET standard conventions.
6 Likes
Neat. After looking at them I was wondering if that WasTheCase.
when you make such decisions you need to consider new users that will see a mix of both, less readable autocomplete list and that unity is a black box so do i care if it’s a property or a variable? no not really
Yes Unity is a black box but knowing whether you are accessing a property or a variable has value when you’re looking to optimize your code. E.g. Time.deltaTime, which feels like it could be a variable set per frame so what’s the cost in querying right? Except caching it for critical path and in loops has a tangible performance benefit because it is a property with a call overhead.
Yes mixing things is unfortunate but so is the old approach of not differentiating, so…
Also, I do realize that the mixing is making this worse for new Users for whom e.g. Time.deltaTime now looks especially like it is not a property. Your concerns are valid and thanks for bringing them up. I just felt like addressing your stance of not caring to know. I too didn’t care once and I think in part because it wasn’t obvious.
2 Likes
From just looking at the new APIs, they’re all in a Unity namespace instead of the UnityEngine namespace. Feels like this is meant to help people identify what context to approach code when it comes to stuff like this and advertise that new subsystems will have a “clean break” from the old style of code.
Would it be impossible to see conversions of old APIs over time? Will new editor subsystems start going into Unity.Editor instead of UnityEditor?
I’m mostly just curious, I started using the .NET style (mostly) and haven’t really looked back.
Sorry, I don’t feel like I’m qualified to give you a definitive or even remotely authoritative prediction on this so I’m going with a definitive probably not maybe… 
Its not a decision we took lightly. There is a big negative impact to change almost every existing API entry point in unity on the ecosystem even with script upgrader support in terms of breaking libraries / code etc.
The approach of new code in Unity namespace following better conventions is what we decided on in the end. And yes we took that decision fully knowing that it leads to a temporary (A couple years) inconsistency in our API’s. It’s better to starting moving code into a new consistent future and not break anything in the process - is the very sumarized conclusion.
8 Likes
This makes it sound like eventually the plan is to remove the old API entirely and just have the new, well written API in a couple of years?
Not saying that’s a bad thing, just curious!
1 Like