Concerning direction of C# naming convention in Unity

In my opinion it's not important what C# naming convention you use, but it's important to be consistent. Consistent in the sense that you use one naming convention for the entire API.

Right now, I found three different naming conventions in Unitys API:

1. The old naming convention everybody knows by now
   
2. .NET standard conventions, see here
3. "Shader programming like everything in lower case" convention, see here

I would very much prefer if you can stick to one naming convention only.

I understand if you want to transition to another naming convention. It means we have to deal with two different naming conventions for a couple of years. Not ideal, but I understand the idea behind it.

What I don't understand is, and believe you don't do yourself a favor by doing that, to add more than two different naming conventions. It's going to make the transition for you even harder.

I also do understand your intention with the new math library to make it easier for shader programmers to write C# math code. But overall, you write C# math code and it should feel like a first class citizen in C# land.

 

Indeed, every language has its own conventions and mixing them to make things "easier" sounds cool at first, but in the end it's C# and *not* GLSL or Cg or anything else.

You could have simply made a wrapper that people can use with

using static GLSLSyntax;

 

ECS is worth keeping how it is, especially if the plan is to generate shader code and vice versa someday. That can be a special case, so long as everything else remains consistent. In many systems, forcing consistency causes more problems than it can solve, just a thought.

So as long as this behaviour is the exception rather than the rule I'm cool with it.

 

You are actually completely right. I have had situations just like that in the past, looking back i think some more leeway would have been a much better choice.

Personally I'd prefer making use of 'using static' whenever possible tho to satisfy both sides

 

I agree this is important.
It is mostly understandable they want to migrate to a .NET Standard naming convention, even if it's a bit annoying. However, the inclusion of "shader programming convention" is totally off putting. So, if I made a library for C# that is inspired by a library from another language, I should change the naming convention just for that library?! The logic simply doesn't hold water. Also, "making it easier for shader programmers" is a totally ridiculous idea. Please consider changing this while the proliferation of this code is minimal.

 

I feel the same way, it's weird to not go with .NET naming standards on math library while other Unity libs transition to it. To me, it feels like the decision over this was made by few people internally because they simply preferred the naming convention themselves. It's not uncommon in this industry to let few specialists have their own way to keep them happy. For example other(tm) game engine I've used let their physics programmers use conventions not allowed in the rest of the engine code.

All in all, if you pick a naming convention, stick to it. It's like 101 thing on all software development. I have no idea why Unity doesn't want to do this.

 

I'd really emphasize the word IF here. If this is the reason for this decision, they should be transparent about it and explain the reasoning.

The explanation I've seen so far is "it's easier to port code from shaders this way" and that is not much of a reason at all, considering how tiny the math lib is and how they need to handcraft every function to play nicely with Burst anyway.

 

I don't think it's a problem. Consistency taken too far is actually a bigger problem especially if it causes more code you have to maintain.

In this case I'm not seeing the problem. It's a math lib. It's really straight forward.

 

Issue isn't if it's easy to use or only on some specific library. If we allow exceptions for every "special" system out there, there's no convention at all. It's bad enough that we have two different naming conventions already, mixing third one there isn't doing any favors to new people trying to understand all this, it's just against all common sense.

I'm not personally upset that Unity does this for the new math lib, it doesn't change way I work in any way. I just wanted to offer my opinion and give support for people who are worried about this as it does fragment the way you use the engine and does it for reasons that are difficult to understand (if there's a hidden agenda behind it, I'd love to hear about it).

 

I only feel bad about the old convention that was made to fit both C# and UnityScript. I wish they hadn't made that choice in the first place.

 

Unity wouldn't be forcing consistency on anyone. The point is, the foundation code should at least follow proper .Net standards throughout (Unity libraries), leaving the user with the choice of following the .Net standards throughout their code, or just ignoring it and doing whatever they want (because it's their own project).

But now, there is no choice. Your code is going to have to be a mix bag of standards because Unity decide they wanted to do that. You can't have consistency if you want to have consistency.

It's almost like they should've just followed the .Net naming standards from the start, they could have avoided wasting all this time fixing their naming standards. I'm sure they won't make a mistake like this again in the future, right? ^_^

 

And why are there special systems at all? How is a special system in line with performance by default, i think by making it a special system you are making it more difficult to use. A higher barrier for entry, maybe some people would not use this new math library because its a special system, and would stick to the old one instead.

 

Upon reflection I concede it would be better to have the syntax cased like Mathf because C# is the most frequent use of Unity mathematics. Parity with shaders would be the minimal use case and something Unity can probably fix their side...

 

Will Mathf be marked with the [Obsolete] attribute when the math library gets integrated?

At least then people would know what to use. If they use those methods in a context where there's no burst compiler or anything, then the methods still work as intended. And when used in ECS then all the better.

I mean why have two static classes with math classes at all.

 

Thank god! Happy to hear that!

 

On this topic, does anyone have feedback for what kinds of Unity-specific fields might need special naming rules, e.g. [SerializableFields] ? The devs for the Rider C# IDE + Unity plugin are wanting feedback but I'm struggling to help:

https://youtrack.jetbrains.com/oauth?state=/issue/RIDER-8339 (Scroll to bottom for last comment by Matt Ellis)

These guys are super responsive, so any guidance here would end up benefiting lots of Unity devs.

 

Super glad to hear that, and that this team exists! There is a lot of feedback in this thread too.
Thanks so much!

 

I believe once there is a library allowed to deviate, others will follow. Just like the broken window theory works.

I understand that and it does make sense. However, float is just a shortcut for System.Single and you probably don't have that "Unity.Single3" type I guess. But I'm totally fine with lower-case types in this case, because I understand the intention.

I would question this one in terms of your global goal to work towards the .NET standards. If you would use CamelCase in this case, it would be quite close to the .NET standard already, considering one thinks of float3 as a shortcut like float is for System.Single.

This decision is hard to understand for me, maybe because you hold some information back. With the current information I have, there is no need to have HLSL-like syntax in C# land.

I don't expect a majority of shader gurus suddenly start writing game code, because the new math library uses a familiar naming convention. I also don't expect the new math library being used completely out-of-context (aka standalone) to the rest of the game code base.

I actually imagine game programmers start to adopt the new math library and incorporate it in their C# game code and then it feels very out of place, like a 3rd class citizen.

 

@xoofx

• Use of lowercase for math functions operating on these vector types (e.g `dot` `mul`...etc.) to better match HLSL like concise syntax

Can you maybe expand on why your team considers this something to be desired? Because by doing this you are deviating from the standards the rest of the C# codebase has, we're obviously not used to this concise standard.

Even for the actual 'first class types' their methods just follow the standards, for example `int.CompareTo`. Whatever a first-class-type is, i've never seen this term used in a C# context. If anything i agree with OP, that by deviating from the standard it looks less built in, less first-class.

 

@JonHUnity @xoofx

Is this only something you guys want? Because I'm not hearing any voices here that really want this new syntax.

Yes, its more in line with hlsl, but is that even something we want in C#?

I doubt that anyone will find it easier to work with C# just because the types and methods of one library are more like what they're used to.

If anything, history has shown time and time again that missing consistency makes it harder for newcomers to get started.

 

Look man I (and we, the community in general) just want to understand what is even going on here, so please don't take the following as an attack or something like that.

Going forward from the points you lined out here: Ok! That sounds cool on paper, but what advantage does that actually have in the end? I for one have not heard programmers using Unity demanding "when will you finally make vectors first class types in unity!??!?"

But what I do hear (here, and in other threads) is that people do not want to have yet another thing they have to get used to. I see a lot of people demanding better organization and more strict adherence to conventions.

What possible gain could there be for the average unity programmer, or even for people coming straight from a shader-language?
Is the only real purpose here to blur the lines between the languages? Is that a good thing even? (I think it is a terrible thing)

I feel you, I'm coming from a different language than C# as well, and it sounds cool to "get the best of both worlds", but my experience in the past was that in the end you won't really feel at home in this new language-mix. All the seams and gaps where the syntax or convention changes are just a constant reminder of something half-baked.

Swizzles are a great thing and are a compatible extension to C#, lowercase field access is not something people will be offended by very much either. But forcefully pressing hlsl shaped methods like "dot", "mul", ... into C#-shaped holes (the whole ecosystem here) is not going to get a great reception except maybe for the hand full of people who told you it was a good idea (as you can clearly see from this thread)

Is it just making unity more accessible for people coming from shading languages?
Why do they need special treatment (so much that even C# programmers who use jobs/ECS have to suddenly adhere to new conventions)?
Those are very intelligent people as well, I'm certain they won't be confused by differently named functions for long.
But I guarantee that more people will be confused by having methods that suddenly go against all the C# conventions they're used to.

So please, explain to us how this massively different convention is supposed to make unity better for the masses.

 

Very fair points, thanks for kindly taking the time to explain above and beyond the call of duty. I think people will definitely appreciate that.