Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

_ field names, CamelCase Properties???

Discussion in 'Scripting' started by techmage, Jan 31, 2015.

  1. techmage

    techmage

    Joined:
    Oct 31, 2009
    Posts:
    2,133
    So following what is shown in the actual MSDN docs I've been doing this:

    public string[] TagArray { get { returntagArray; } set { tagArray = value; } }
    private string[] tagArray;

    As of late I notice some people, particularly prime31 use this:
    public float delay { get; private set; }
    private float _delay;

    Whats going on here and why? Does anyone have any reasoning for this? What is really the ideal way to do this? I figured following MSDN docs was ideal.
     
  2. Polymorphik

    Polymorphik

    Joined:
    Jul 25, 2014
    Posts:
    599
    You are doing it right, what I think happened is Unity was trying to promote UnityScript which follows JavaScript notation. Though, C# is the dominate language professionally and personally the better language because you can actually reuse C# scripts with actual C# programs.

    Anyways just follow MSDN for correct coding style and notation like you have been.
     
  3. Jessy

    Jessy

    Joined:
    Jun 7, 2007
    Posts:
    7,325
    Microsoft made the conventions, but Microsoft doesn't code as much as people who understand why Microsoft got it wrong. It's not their "fault". You don't have the same potential to use tools if you make them.
     
  4. Polymorphik

    Polymorphik

    Joined:
    Jul 25, 2014
    Posts:
    599
    I just looked at Prime31 and they are not following the rules and guides laid out by Microsoft. It looks like they are following C/C++ and JavaScript notation and not C#/Fortran notation.

    Programming languages have their own conventions respectively to keep things clean, consistent and global. Follow MSDN and not what other people do. If you ever want to get a job professionally the first thing they will look is your coding style.

    Keep doing what you are doing, follow MSDN and you'll be golden :)
     
  5. techmage

    techmage

    Joined:
    Oct 31, 2009
    Posts:
    2,133
    What do you think is the ideal way and why?
     
  6. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    They are following the Unity standards. That's how Unity code is written; see the docs for many examples.

    It does not. e.g., Javascript names functions "likeThis" whereas Unity names functions "LikeThis".

    --Eric
     
  7. Polymorphik

    Polymorphik

    Joined:
    Jul 25, 2014
    Posts:
    599
    Unity has no code, its based on the Languages the Unity3D Engine supports. They just have a series of backend functionality that C#, JavaScript and Boo and connect to. All conventions are based on their respective languages.

    Hence my second comment where I looked and corrected myself pointing to Prime31 not following the conventions. Even if you are exposing external code from Obj-C or C/C++ the C# scripts or code files must abide by their respective standard.
     
  8. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    Of course it does. The Unity coding convention is that classes and methods are UpperCase, variables and properties are lowerCase. This is the same for all the languages in Unity; look at the docs and other material (tutorials etc.).

    --Eric
     
    Kiwasi likes this.
  9. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    Huh, never noticed the difference between the MSDN and Unity conventions.

    Unity conventions are for properties and fields to both use lower case, and to use the _on backing fields.

    This actually makes a lot of sense. Properties and fields are essentially interchangeable. The end uses does not need to know which he is using. It is worth the end user being able to distinguish between properties and methods at a glance, because their uses are quite different.
     
  10. Dameon_

    Dameon_

    Joined:
    Apr 11, 2014
    Posts:
    542
    Casing conventions vary from programmer to programmer. The MSDN is not the bible on how your code should appear. The important things are consistency within your own code and ability to follow other peoples' conventions when working with their code, or in a group project.
     
  11. Jessy

    Jessy

    Joined:
    Jun 7, 2007
    Posts:
    7,325
    I do not consider my rationale a matter of stylistic opinion, but one of practicality. I have no visual preference to one style or another; I just want to name things what I want, and have the code compile. As our programming languages' keywords are written in English, they should work within the construct of the English language:

    In C#, you can't have properties and methods with the same name, regardless of method signature. If you follow Microsoft, you can't share names for things that are both verbs and nouns; going with the Unity conventions solves that. It also allows for more nesting, avoiding cluttering up your namespaces:
    Code (CSharp):
    1. class CheshireCat {
    2.     CheshireCatGrin grin;
    3.     void Grin(CheshireCatGrin.Quality quality) {grin = new CheshireCatGrin(quality);}
    4. }
    5. struct CheshireCatGrin {
    6.     public enum Quality {toothy, mischievous}
    7.     public readonly Quality quality;
    8.     public CheshireCatGrin(Quality quality) {this.quality = quality;}
    9. }
    Here's Microsoft's:
    Code (CSharp):
    1. class CheshireCat {
    2.     CheshireCatGrin ShouldBeGrinButCannotBe;
    3.     void Grin(CheshireCatGrinQuality quality) {
    4.         ShouldBeGrinButCannotBe = new CheshireCatGrin(quality);
    5.     }
    6. }
    7. struct CheshireCatGrin {
    8.     public readonly CheshireCatGrinQuality Quality;
    9.     public CheshireCatGrin(CheshireCatGrinQuality quality) {Quality = quality;}
    10. }
    11. enum CheshireCatGrinQuality {Toothy, Mischievous}
    Now, while the former is the lesser of two C# evils, neither is "ideal". Swift allows for the ideal case:
    Code (Swift):
    1. class CheshireCat {
    2.     var grin: Grin!
    3.     func grin(quality: Grin.Quality) {grin = Grin(quality)}
    4.  
    5.     struct Grin {
    6.         enum Quality {case toothy, mischievous}
    7.         let quality: Quality
    8.         init(_ quality: Quality) {self.quality = quality}
    9.     }
    10. }
    Note: I would normally use partial classes or class extensions for nested types, instead of the maximum brevity used above.
    Another Note: Neither C# nor Swift allows having a property and argument-less method with the same name. I consider this a bug.

    The convention of using PascalCase for type names, and camelCase for members, assists with static members of members that are named the same as their type. Syntax highlighting in MonoDevelop makes this example clear, but we can't rely on that highlighting; this forum doesn't get it right, for instance.
    Code (CSharp):
    1. Color Color = Color.red;
    2. Color color = Color.red;

    Prime31 uses camelCase for methods. I believe he considers this to require fewer cognitive resources, as he uses several languages, and all of the other ones use that convention.
     
    Last edited: Jan 31, 2015
  12. cmcpasserby

    cmcpasserby

    Joined:
    Jul 18, 2014
    Posts:
    315
    You can use the style you want for personal projects, if you are working on a team use the style they use.

    I am partial to using the underscore but I'm sure that is mostly to having a python background
     
  13. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    Not sure how you could do this if you want to hold on to the reflection abilities. How would you distinguish between the two?
     
  14. Jessy

    Jessy

    Joined:
    Jun 7, 2007
    Posts:
    7,325
    The CLR can distinguish between methods, properties, fields, and other members. I'm confused about what you think wouldn't work. C# even allows you to get around the limitation with extension methods (this does not work in Swift). Check out MonoDevelop's autocomplete using Reflection to get the type of the member:
     

    Attached Files:

  15. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    @Jessy This is the simplest use case I can see going wrong.

    Code (CSharp):
    1. public class MyClass {
    2.     float myFloat {get; set;}
    3.  
    4.     float myFloat () {
    5.         // return a float
    6.     }
    7.  
    8.     void SomeFunction () {
    9.         var someValue = myFloat;
    10.     }
    11. }
    I'm no expert, but it seems allowing a property and a method to share identical names would cause other problems. It might be fixable, but it would require some overhaul.
     
  16. Jessy

    Jessy

    Joined:
    Jun 7, 2007
    Posts:
    7,325
    Your issue would only become problematic if delegates could be created from methods using var, but they can't, as the type cannot be inferred. Your var would only take the property; you'd need to explicitly type it as Func<float>, to store the method. The compiler is apparently not bright enough to allow us to do anything cleaner than this, if myFloat is also a property/field:
    Code (CSharp):
    1. Func<float> someValue = () => this.myFloat();
    2.  
    3. public static class MyClassExtensions {
    4.     public static float myFloat(this MyClass _) {return float.MaxValue;}
    5. }
     
    Last edited: Jan 31, 2015
  17. techmage

    techmage

    Joined:
    Oct 31, 2009
    Posts:
    2,133
    Is this documented anywhere?

    I was just looking through the unity UI examples and noticed they actually have m_ before private fields.
     
  18. cmcpasserby

    cmcpasserby

    Joined:
    Jul 18, 2014
    Posts:
    315
    Really much of it is up to personal style. Work how you want, if you work on a team decide and documeant your standard.
     
  19. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    And if you have no style, copy the documentation / community you use most often.
     
  20. cmcpasserby

    cmcpasserby

    Joined:
    Jul 18, 2014
    Posts:
    315
    Ya I guess peoples style comes a lot from previous languages they have worked with. A lot of how I write is based on pythons pep8 with a few of the conventions of java tossed in, than just some preference stuff.
     
  21. jhina

    jhina

    Joined:
    Apr 6, 2015
    Posts:
    2
    Can someone point me at the documentation where MSDN specifies that private fields should be lowercase? If I recall, the Microsoft documentation abstains from declaring any rules around private fields. Their logic is that the private fields can never be part of a public API therefore they don't care.
     
  22. Jessy

    Jessy

    Joined:
    Jun 7, 2007
    Posts:
    7,325
    Who said that? They don't make a distinction between public or not. Why would you bother making a different rule for each? It's an IDE's job to tell you what's private or not, not naming.
     
  23. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,514
    You can find it referenced here:
    https://msdn.microsoft.com/en-us/library/ms229045(v=vs.110).aspx

    And it's generally considered in any scope.

    Personally I think the not using _ is ballocks, as one will notice looking at my code on git.
     
  24. LaneFox

    LaneFox

    Joined:
    Jun 29, 2011
    Posts:
    7,462