Search Unity

Naming convention inconsistencies

Discussion in 'Data Oriented Technology Stack' started by Malmer, Apr 4, 2018.

  1. Malmer

    Malmer

    Joined:
    Nov 10, 2013
    Posts:
    17
    Any reason why the new ECS system use PascalCase for all public/protected fields/properties, while the rest of Unity (including the brand new scriptable rendering pipeline) use camelCase?

    Will this be the standard for all Unity things going forward, and all older APIs will use camelCase, but all new packages use PascalCase?

    Would prefer it to be consistent across the whole Unity API, which in this case means staying with the same naming conventions as the rest of Unity.

    Please pick one standard and use for everything.
     
    Last edited: Apr 4, 2018
    RaL, GameDevCouple_I and StephanK like this.
  2. RaL

    RaL

    Joined:
    Nov 29, 2013
    Posts:
    27
    Yeah... Those are not the only inconsistencies. Have you seen the new mathematics API yet? There are classes and methods with names starting in lower case all over the place (math.cos(), math.sin(), math.lengthSquared(), ...) I saw a thread on reddit where someone from Unity said it was to match HLSL - although I'm not sure why that would be necessary or desirable.

    I don't think it's that big of a deal, I can live with naming inconsistencies just fine, but I'm pretty sure threads like yours will pop up here and on reddit a lot in the future... Most programmers are very anal about proper naming :D
     
  3. runner78

    runner78

    Joined:
    Mar 14, 2015
    Posts:
    56
    The "old" Unity naming for properties is inconsitent to the C# naming convention. The .NET Framework using UpperCamelCase for all public properties.
    The naming of the new math API make's no sence, C# is C#, HLSL is HLSL...
     
    RaL likes this.
  4. LaneFox

    LaneFox

    Joined:
    Jun 29, 2011
    Posts:
    6,435
    IIRC there was some talk about them changing the naming convention to match .NET?

    Obviously, it wouldn't go backwards because it would break everything, so there's some inconsistency.
     
  5. Malmer

    Malmer

    Joined:
    Nov 10, 2013
    Posts:
    17
    I just want consistency. Doesn’t matter really which style they go for. Allthough I do like the old style because there is no risk in mixing what is a static class and what is a property when casually reading the code. The EntityManager property of ComponentSystem is a good example of that.

    But if they go with the new style then they should use that for all new things, such as the SRP and the new math library. This mix is no good.
     
    RaL and FROS7 like this.
  6. superpig

    superpig

    Quis aedificabit ipsos aedificatores? Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,184
    It's intentional. All the old code (in the UnityEngine and UnityEditor namespaces) will continue to use the old style, and all the new code (in the Unity namespace) will use the new style.

    We know it's inconsistent, but we want to be more in line with the rest of the .NET ecosystem, and this is the most practical way to make the transition. Over time, more and more of what we're releasing will be in the Unity namespace, and the UnityEngine/UnityEditor will become a land of legacy.
     
    JoaoBorks, Jobus, Cynicat and 2 others like this.
  7. RaL

    RaL

    Joined:
    Nov 29, 2013
    Posts:
    27
    What about the math library?
     
  8. Antony-Blackett

    Antony-Blackett

    Joined:
    Feb 15, 2011
    Posts:
    1,282
    Does it matter? Auto complete ftw.
     
    Cynicat, RaL, Rennan24 and 1 other person like this.
  9. StephanK

    StephanK

    Joined:
    Jul 10, 2012
    Posts:
    46
    Will you adopt the standard code style for .net, or create your own variation of it? Is there a reference for it? If more and more unity code will be written in C# it would be actually nice to keep our own style to match unity's.
     
  10. Rennan24

    Rennan24

    Joined:
    Jul 13, 2014
    Posts:
    30
    Personally I don't mind the inconsistency as long as its moving towards a more consistent route. And I can't wait till all my using statements are starting with Unity! I also don't really mind that the math library is like HLSL, maybe its because I have been writing shaders for Unity, and now that the new Node based shader creator is coming out I might start leaning more towards the .NET naming convention. Also I would love to see some reference for the new naming convention. :D
     
    RaL and FROS7 like this.
  11. RaL

    RaL

    Joined:
    Nov 29, 2013
    Posts:
    27
    The new naming convention is: properties, type names and method names absolutely always start in uppercase. Unless they don't because they're...uhm... math related? I guess? No rules apply when it's math :D
     
    StephanK likes this.
  12. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    255
    I personally really like the convention for the math library. There are TONS of good math examples in HLSL that are now just copy-paste. plus HLSL's naming convention is really slick, for example length is much easier to understand what it means than magnitude, especially for beginners.
     
    Rennan24, FROS7, Krajca and 1 other person like this.