Search Unity

  1. We are migrating the Unity Forums to Unity Discussions. On July 12, the Unity Forums will become read-only. On July 15, Unity Discussions will become read-only until July 18, when the new design and the migrated forum contents will go live. Read our full announcement for more information and let us know if you have any questions.

Question Vote for coding standards

Discussion in 'Open Projects' started by Kamyker, Oct 1, 2020.

?

Pick max 2 preferred coding standards/naming conventions

  1. C# (uppercase public fields)

  2. C++ (lowercase public fields)

  3. NO prefix for private fields (playerHealth)

  4. "_" prefix for private fields (_playerHealth)

  5. "m_" prefix for private fields (m_playerHealth) (used in fps microgame)

  6. Whatever (aka complete mess)

Multiple votes are allowed.
Results are only viewable after voting.
  1. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,092
    You can select 2 options:
    - C# or C++
    - preferred prefix for private fields/member variables

    Good to see this project happening, almost exactly what I proposed twice:
    Tbh I'd rather see few smaller projects instead of one massive one as it will be tough to keep it updated with the engine.
     
    Proryanator likes this.
  2. Jirushi

    Jirushi

    Joined:
    Jan 17, 2020
    Posts:
    33
    I prefer to stick with Rider's standards, but not everyone uses Rider I guess
     
    Ruchir and CharlExMachina like this.
  3. CharlExMachina

    CharlExMachina

    Joined:
    Jun 18, 2017
    Posts:
    9
    I also prefer Rider's standards. They're very sane and it helps keep the code consistent with general C# style guidelines
     
  4. KingAustin

    KingAustin

    Joined:
    Jan 12, 2016
    Posts:
    20
    you guys use uppercase public fields.
    i was taught in programming, idk what language maybe c# dont use other languages. I was told that variables, all variables would have a lowercase and methods and other important stuff would have an uppercase. Have i been mistaught
     
    FancifulEight, Hades98 and lmbarns like this.
  5. ProgrammerTurtle

    ProgrammerTurtle

    Joined:
    Oct 8, 2018
    Posts:
    28
    Each language has it's own convention. Not to mention that most of the time frameworks also has their own naming conventions too.
     
  6. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    In fact I quoted one of your posts in my proposal, back in April ;)

    What do you mean? Are you referring to this project when you say "massive"?
     
  7. Jirushi

    Jirushi

    Joined:
    Jan 17, 2020
    Posts:
    33
    I must guess it' s because C# has properties, which are basically shortcuts for Get Set methods, and public variable are very similar to properties when viewed from outside
     
  8. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,092
    Could you send a link or explain exactly how Rider's differs from C#?
     
  9. CharlExMachina

    CharlExMachina

    Joined:
    Jun 18, 2017
    Posts:
    9
    Rider's standard is the same C# standard. The IDE just actively enforces it

    What he meant, is mainly always using var except for when you can't. Writing public variable and function names in PascalCase, declaring private variable prefixed with an underscore (private float _movementSpeed), and private serialized fields with camelcase without using the underscore
     
    Last edited: Oct 1, 2020
  10. hddnblde

    hddnblde

    Joined:
    Jan 10, 2015
    Posts:
    6
    If we were to go with private fields not using m_ but instead just pascalCase, how do we deal with properties? Are properties gonna be UpperCase (CamelCase)?

    I'd like to adopt any convention that will be chosen but for me the idea of using m_ for private is:

    private int m_hitPoints = 100;
    public int hitPoints => m_hitPoints;

    But yeah I'm pretty excited for the project regardless. :D
     
    PitaBreadGames likes this.
  11. Antony-Blackett

    Antony-Blackett

    Joined:
    Feb 15, 2011
    Posts:
    1,779
    I don’t care, as long as it’s consistent, doesn’t get in the way of autocomplete, doesn’t create resistance to refactoring and change and is human readable.
     
    VenetianFox and cirocontinisio like this.
  12. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,092
    :rolleyes: hmm I'll try my luck: what about making Unity source-available like Unreal? (just kidding... or?)

    Yes, well looked through the cards and maybe it's not massive but compared to all other Unity samples/projects it's going to be the biggest one in terms of connected gameplay systems. It may be a real challenge to maintain if it gets too popular. If that happens then creating multiple projects with community github moderators/reviewers (like bitcoin) could be good.

    Tbh I dislike a bit that Unity LTS version was picked but I guess this particular project is meant to be stable for learning experience not exactly improving Unity. For future projects (or some of them) consider using the newest non-beta version ;).
     
  13. Braneloc

    Braneloc

    Joined:
    Nov 28, 2012
    Posts:
    8
    No public fields, no prefixes - public PascalCaseProperties => private [SerializeField] inCamelCase as per original C# naming conventions.
    Prefixes are redundant if you are using an IDE and reduce readability, it makes it look like you are doing something special or have got the discard character wrong. It's not C / C++ in the 90s.
     
  14. philipeng

    philipeng

    Joined:
    Oct 3, 2019
    Posts:
    11
    I would go with Rider's standard as well. Makes thinks more organised and clear for anyone joining the project Thou, just having any standard would be awesome as the project's idea is pretty cool. Look forward to contributing to it.
     
    CharlExMachina likes this.
  15. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,092
    Enforcing these specific cases won't be easy.

    I'm not a fan of var everywhere, ptsd from js.
     
    Last edited: Oct 1, 2020
  16. PitaBreadGames

    PitaBreadGames

    Joined:
    Sep 15, 2017
    Posts:
    5
    I prefer no prefix. Same reasons Braneloc mentioned:
    That being said, as long it's consistent, I'm cool with it. Is there an official deadline on the voting?

    ----------------------------------------------

    Commenting Standards - Where are they? o_O
    Obviously, explain with good naming and readable code, but we're probably gonna want comments, too.
    I suggest:
    - Write comment above every class that says the class' purpose. Optionally, include details about how the class works, especially if it's not particularly intuitive or readable.
    - Precede each comment with a "signature" that includes git username and date comment was written.
    Code (CSharp):
    1. // UnityTechnologies 9/30/2020
    2. // comments here
    Sidenote: It brings me joy no one voted for "Whatever (complete mess)" :D
     
    Last edited: Oct 1, 2020
    float likes this.
  17. MagdielM

    MagdielM

    Joined:
    May 27, 2020
    Posts:
    32
    I second this. The Microsoft spec is probably more thorough and thought-out than any standard we can come up with in any reasonable period of time.

    Some may be concerned that these guidelines are now 12 years old, but this section of the C# programming guide in the official .NET docs references them, and that was just two years ago.
     
    float and PitaBreadGames like this.
  18. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,092
    There's some advantages to using public properties only instead of public fields but they make project a bit more complicated for new users.

    Up to @cirocontinisio if another voting will be needed or rather keep it simple for the 1st project.
     
  19. Braneloc

    Braneloc

    Joined:
    Nov 28, 2012
    Posts:
    8
    Things should only be public if they are to be used in other classes. If not, it adds to complexity :/ Encapsulation!
    Code should always be descriptive - public properties make it clear what is read/write and what should be used.

    Also - lets please get rid of magic numbers in code - I'm looking at you Character.cs (and that Update method is huuuge)

    If you are looking at complexity, git can be completely overwhelming to new git users. Wait, official Unity Asset Store GitHub but it's a plugin not a package and not included, Visual Studio integrated but where's the tab, GitHub desktop - there's 4 versions of my copy now, sourcetree won't run and that guy on the internet says command line except he's on a mac and... now the fork is behind.. and none of these git words make sense.. :) Oops, I went off topic :)
     
  20. grizzly

    grizzly

    Joined:
    Dec 5, 2012
    Posts:
    357
    I find it easier to differentiate between private fields and local variables when prefixed, but it's ultimately down to personal preference - as per the C# guidelines:

    "The field-naming guidelines apply to static public and protected fields. Internal and private fields are not covered by guidelines"
     
  21. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,092
    Change color of fields in IDE.

    The only advantage of underscores is being able to quickly pull up intellisense with fields list, useful in big classes, waste of time in smaller ones.
     
  22. Semetre

    Semetre

    Joined:
    Feb 18, 2018
    Posts:
    5
    I vote for Rider standards, too: prefixes for private fields. That said, I think public fields should be camelCase and properties should be PascalCase.
     
    CharlExMachina likes this.
  23. MartinIsla

    MartinIsla

    Joined:
    Sep 18, 2013
    Posts:
    104
    I absolutely agree with you!
    • camelCase for public
    • camelCase with "_" prefix for private
    • PascalCase for methods and public variables with access modifiers
    We can have an editorconfig file that enforces these styles. I can create it.

    I'd also add having attributes (such as [Tooltip] or [SerializeField]) in different lines.
     
  24. tmcdonald

    tmcdonald

    Joined:
    Mar 20, 2016
    Posts:
    160
    I agree with this. I would add that my preference would be to keep public fields to a minimum. I'd prefer private fields with the [SerializeField] attribute.
     
    CharlExMachina and MartinIsla like this.
  25. MartinIsla

    MartinIsla

    Joined:
    Sep 18, 2013
    Posts:
    104
    Absolutely, that's a must.
     
    tmcdonald likes this.
  26. grizzly

    grizzly

    Joined:
    Dec 5, 2012
    Posts:
    357
    In an IDE, sure, but Open Projects are hosted on Github where such distinction is advantageous to readability.
     
  27. TheReaperGames

    TheReaperGames

    Joined:
    Jan 10, 2017
    Posts:
    2
    Will you implement public variables with access modifiers or getters/setters?
     
  28. Dustin_00

    Dustin_00

    Joined:
    Feb 26, 2013
    Posts:
    14
    I *hate* var everywhere.
    Code (CSharp):
    1.   var result = SomeFunction(var1, var2);
    2.   gameObject.method(result);
    What is result???
    This is so useless for code reviews and makes for hideous ramping up and debugging.

    And C# styles get confusing when mixed in with the Unity JavaScript-styled libraries:
    Code (CSharp):
    1.   myGameObject.transform.localPosition = myVector;
    (Although I do love the C# standard styles and am happy if we stick with them for the project.)
     
    SideSwipe9th likes this.
  29. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,092
    That's the C++ convention in the poll. It's not the case everywhere, newer packages use uppercase public properties/fields like Addressables, Jobs, Entities.
     
  30. Neonage

    Neonage

    Joined:
    May 22, 2020
    Posts:
    288
    Are you writing in notepad?
     
  31. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,092
    Github viewer is kinda a notepad and also hovering over a variable/method to see its type is a waste of time.

    Use var if it makes sense and type is visible within few lines.

    This project and its code will be reused by many users, readability is the top priority.
     
    float and SideSwipe9th like this.
  32. SideSwipe9th

    SideSwipe9th

    Joined:
    Jan 10, 2019
    Posts:
    46
    I agree with @Dustin_00 , using var everywhere is a nightmare from a code review point of view. Per Dustin's example, what is result? Is it a standard type like int or string? Is it a List or Dictionary? Is it a class? Without looking at either the SomeFunction function, or the gameObject.method function you have no idea what that may be returning. And what if someone later changes what SomeFunction returns, but not the input for gameObject.method? Congratulations, you've now got an error in the Unity console that may not be clear.

    When the goal of this project is partially teaching, using var will make it much less accessible for newer programmers. I'd recommend we avoid them as much as possible.

    Exactly this. In the time it takes you to hover over a var type and for the popup to appear after Intellisense guesses what the variable type is, I could have pressed my F12 key and already be at the definition for the custom class. Being explicit in what type a variable is aids that goal by aiding readability.
     
    float and kcastagnini like this.
  33. Neonage

    Neonage

    Joined:
    May 22, 2020
    Posts:
    288
    Oh, okay, in that case I agree on that.
    But "_" prefix kills readability :D
     
    float and RodrigoAbreu like this.
  34. tmcdonald

    tmcdonald

    Joined:
    Mar 20, 2016
    Posts:
    160
    I used to be against the underscore private field prefix until I was convinced by a rather compelling argument that it helps differentiate members from locally scoped variables. In my day job, I rarely use fields so it hardly matters. I don't have a strong opinion on the matter.

    However, I definitely prefer using var when possible. Variable names should be meaningful and having the type explicitly presented next to the variable is no excuse for poor naming. That being said, I'll agree to community preference on it. I will say that assignments where the type is obvious should be exempt and the programmer should prefer implicit typing:

    Code (CSharp):
    1. var item = new Item();
    2.  
    3. var inventory = GetComponent<Inventory>();
     
  35. Neonage

    Neonage

    Joined:
    May 22, 2020
    Posts:
    288
    It doesn't.
    I've made theme for Rider that makes locals gray, reassigned italic, members cyan, properties purple, and statics bold.
    That's what actually makes code readable and keeps your eyes pleased upload_2020-10-2_1-58-40.png
     
    xiao-xxl and float like this.
  36. tmcdonald

    tmcdonald

    Joined:
    Mar 20, 2016
    Posts:
    160
    Let me know if you find something that works for VS Code, I don't see anywhere I can customize the color of field variables specifically. In the meantime, I'd also recommend taking a gander at changing your font to Fira Code, it has ligatures that are amazing for code readability.


     
  37. Neonage

    Neonage

    Joined:
    May 22, 2020
    Posts:
    288
    VS Code is not an IDE for me :D

    Any font rather than JetBrains Mono looks awful in Rider, especially with bold italic usage
     
  38. tmcdonald

    tmcdonald

    Joined:
    Mar 20, 2016
    Posts:
    160
    Well I could be wrong but I suspect more people are using VS Code and Visual Studio 2019 Community to contribute than Rider. So to that end I'd probably still prefer the prefix for readability (and of course that's not even including the code reviews in github.)
     
    RodrigoAbreu and kcastagnini like this.
  39. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,092
  40. kcastagnini

    kcastagnini

    Joined:
    Dec 14, 2019
    Posts:
    63
    Private fields without "m_" or "_" shouldn't even be an option IMO.
    Without prefixes it will become a pain in the neck to distinguish between local variables and fields.

    Code should be always readable, regardless of the IDE.
    Plus rider is behind a paywall, correct me if I'm wrong.
     
    Last edited: Oct 1, 2020
    SideSwipe9th likes this.
  41. Sangemdoko

    Sangemdoko

    Joined:
    Dec 15, 2013
    Posts:
    224
    I agree with @kcastagnini and @tmcdonald, I think it's a good idea to adopt a solution that works well for any IDE or code editor of choice.

    So either "_" or "m_" is good for private and protected fields.
    I have a preference for Pascal case for public properties to differentiate them from local variables.

    As for the the use of var. I find it extremely useful for refactoring. I'd also argue the the function names should be sensible and the type returned should be implicitly evident.

    Also I believe abbreviations should be avoided as much as possible. I prefer a lon variable name that makes sense than a small one that leaves me with doubts
     
    SideSwipe9th likes this.
  42. kcastagnini

    kcastagnini

    Joined:
    Dec 14, 2019
    Posts:
    63
    Yes I'd love PascalCase for public fields me too, camelCase for local vars and _camelCase (or m_camelCase) for private fields.
    If we use camelCase for everything it will become a huge mess.
     
    MUGIK likes this.
  43. Neonage

    Neonage

    Joined:
    May 22, 2020
    Posts:
    288
    I'll never understand that.. I haven't encountered such problems when used VS, even in the messiest code.
    Members are always at the top, you read them first and you know them.
    Locals are, well, locally, so it's easy to see them without much scrolling.
    If you have "somethingList" as member it would be just "list" locally, and you know what it is, cause it's made in CreateSomethingList().

    And when i'm looking at the Unity's source code, i'm just getting distracted to all "s_" and "m_"' 's, it just makes code ugly and doesn't help.
    Good names and methods split - that's what helps
     
    Vharz, indexhever and RodrigoAbreu like this.
  44. ChemaDmk

    ChemaDmk

    Unity Technologies

    Joined:
    Jan 14, 2020
    Posts:
    65
    Hey all ! Thank you for your input, we're putting together a document with some coding standards following what you suggested. We'll post it soon.
    Stay Tuned !
     
  45. kcastagnini

    kcastagnini

    Joined:
    Dec 14, 2019
    Posts:
    63
    I find really readable private properties with _ or m_ on the other hand, because I can immediately understand if a variable is a private field or local variable without scrolling or remembering all the fields.
    Plus by typing _ I get all the suggestions by IntelliSense.
    It's just my preference anyways, I'm just used to it.
     
  46. Deleted User

    Deleted User

    Guest

  47. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,092
    My short and simple summary of the whole thread and polls (tabs vs spaces):

    - PascalCase: classes, methods, enums, namespaces, public fields/properties
    - camelCase: local variables, methods parameters
    - _camelCase: private fields/properties
    - use [SerializeField] private instead of public when possible to expose fields in the editor
    - (optional) try to use public properties instead of public fields
    - tabs, not spaces

    Obviously don't use it, wait for guidelines from Unity.
     
    circa94 and Zold2012 like this.
  48. indexhever

    indexhever

    Joined:
    Mar 30, 2012
    Posts:
    6
    I'm with @Neonage and "Uncle Bob" on this. Prefixes and suffixes are not necessary with the IDEs we have nowadays. You should just keep your classes small, following SOLID principles. Actually, it is better to hide a field that would be public in a Property.
     
  49. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,092
    Often times on github you read and discuss code snippets not whole files.
     
    kcastagnini and SideSwipe9th like this.
  50. GregoryFenn

    GregoryFenn

    Joined:
    Feb 13, 2018
    Posts:
    43
    Ahh but a C# field is really just a neat way of encoding a getter and/or setter method. In fact the motivation for using uppercase fields and properties and methods is that the client to the API shouldn't need to know what it is! A field like .Speed could be a getter property or a public field for all the client cares.