Search Unity

  1. Looking for a job or to hire someone for a project? Check out the re-opened job forums.
    Dismiss Notice
  2. Unity 2020 LTS & Unity 2021.1 have been released.
    Dismiss Notice
  3. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

Suggesting solutions for SerializeField warning

Discussion in 'Scripting' started by miniwolf_unity, Sep 1, 2020.

Thread Status:
Not open for further replies.
  1. miniwolf_unity

    miniwolf_unity

    Unity Technologies

    Joined:
    Apr 10, 2018
    Posts:
    103
    Summary of the problem

    https://issuetracker.unity3d.com/product/unity/issues/guid/1080427/

    Back in 2018.4 a decision was made to remove the suppressor on the warning known as CS0649. This warning appears when a private or internal field is declared but never assigned a value.

    When a MonoBehaviour contains a field that is private. One can add the attribute [SerializeField] to have the value shown in the inspector. This is because the inspector only shows serialized data and private fields are not serialized.

    Since the removal of the suppressor, users have been seeing this message on their code:

    “Assets\NewBehaviourScript.cs(8,12): warning CS0649: Field 'NewBehaviourScript.myField' is never assigned to, and will always have its default value null”

    What we want from you
    Please answer the following in a reply in this thread:
    1. What's your level of unity experience?
    2. What's the current project you are working on?
    3. Which solution should we implement for 2018.4 LTS, 2019.4 LTS and 2020.2 based on the list below?
    4. Which solution should we focus on for new releases of Unity 2021.1 and above, based on the list after the solutions for 2018.4, 2019.4, and 2020.2?
    Solutions for 2018.4, 2019.4, and 2020.2
    Project Setting, reorderable list
    In the project settings window we add a list of default suppressed warnings. This gives you the ability to keep or remove the list of suppressed warnings. In addition, this allows you to add new compiler arguments that you want to pass to the compiler. The arguments will be passed to every assembly being compiled in your project. In addition to suppressing the warning for SerializeField, the warning will also be suppressed for any other valid cases.



    Project setting, checkbox
    In the project settings window we add a toggle button to enable and disable a built-in list of these suppressed warnings. Compared to the list approach, you cannot add or remove any of the suppressors individually. As with the previous solution this will not only suppress the warning for SerializeField, the warning will also be suppressed for any other valid cases of this warning.



    Suppress the Warning by Default
    In this case we would suppress the warning by default. There will be no UI to either enable or disable the behaviour. This was the old solution before the regression was introduced. This will work exactly as in 2017.4.

    Nothing
    None of the solutions will be applied. You can use one of the following workarounds to resolve the problem.
    Today you can remove the error by adding the following pragma statements in your code:

    Code (CSharp):
    1. #pragma warning disable 0649
    2. [SerializeField]
    3. private string m_MyField;
    4. #pragma warning restore 0649
    This will suppress the individual warning the pragma block is covering.

    Another possibility today is to add a csc.rsp file the file content:
    Code (CSharp):
    1. -nowarn:0649
    By changing the field to public and not using SerializeField the warning will not be shown.
    Assigning a default value to the field will do the same.

    Solutions going forward
    In order to make a more focused solution to this problem, we want to hear which solution we should be implementing going forward.

    Assembly Definition Inspector
    In the inspector of an .asmdef file we add a field where you can type in the additional compiler arguments you want to pass along. These arguments can be any of the ones supported by the Roslyn Compiler.
    By suppressing the warning in this fashion this will not only suppress the warning for SerializeField, the warning will also be suppressed for any other valid cases of this warning.

    This method will only work if your code is structured in this manner. If you do not have an asmdef for the project, it will not be possible to add these additional arguments.

    This will function similar to the Project Setting approach. The main difference will be that this setting is per assembly. This will allow the assembly to add additional compiler arguments in addition to the ones that are hardcoded.



    Roslyn Analyzer
    With the newly added support for Roslyn Analyzers in 2020.2, we can add an analyzer to specifically suppress the warning for SerializeField. This will not add the ability to add additional compiler arguments.

    We would ship these analyzers as a package that can be added to the project. They would work the same way as Visual Studio and JetBrains today is suppressing this warning in their code editors. These analyzers can be found here: https://github.com/microsoft/Microsoft.Unity.Analyzers and can be used in 2020.2 in the newest release of the code editor.

    In addition, we can append a better message to the compiler warning to notify users about this possibility of adding the package to suppress the warning for SerializeField.

    Changing Best Practices
    We update our documentation to explain that a field should be public if you want it visible in the inspector. Rewrite the SerializeField documentation with a note that this pattern is not recommended and the issue that one can run into.

    In addition we can append a better message to the compiler warning to notify users that this pattern is not recommended and to make the field public or assign a value to it in the code.
     
    ModLunar, McDev02, SparrowGS and 10 others like this.
  2. OrioliBublar

    OrioliBublar

    Joined:
    Jun 28, 2017
    Posts:
    5
    1. Mid-upper level, 4 years professional.
    2. Location-based mobile game based on a large IP.
    3. Project Setting, reorderable list with sane defaults is something that would provide the best balance of customizability and discoverability for both junior and senior devs.
    4. Roslyn Analyzer sounds like a good approach, it would also act as a nice way to introduce developers into the existence of analyzers, and the world of static-code checking.
    Please, for the sake of everyone working on larger projects/teams remove even the mention of:
    We update our documentation to explain that a field should be public if you want it visible in the inspector. Rewrite the SerializeField documentation with a note that this pattern is not recommended and the issue that one can run into.

    In addition we can append a better message to the compiler warning to notify users that this pattern is not recommended and to make the field public or assign a value to it in the code.
    It is already hard enough to explain API design and data access control to new developers who only get Unity education without any engineering background without public fields being the only way of serializing things.
     
    Ryiah, Reahreic, Senshi and 7 others like this.
  3. PraetorBlue

    PraetorBlue

    Joined:
    Dec 13, 2012
    Posts:
    5,501
    1. Longtime Unity hobbyist - intermediate level. Professional software developer.
    2. Single player physics-based puzzle game.
    3. I like the first option - Project Setting, reorderable list. Adding defaults for new projects would be a good idea as well.
    4. Roslyn Analyzer solution looks the nicest to me. I especially think Changing Best Practices to encourage public fields would be a mistake. It encourages bad code. Specifically it encourages users to violate the Encapsulation principle of Object Oriented Programming by having public fields all over the place.
     
    Last edited: Sep 1, 2020
    Ryiah, Tarball, angrypenguin and 6 others like this.
  4. Jigoku

    Jigoku

    Joined:
    Jan 10, 2014
    Posts:
    5
    I agree with theOrioli and PraetorBlue that encouraging public fields is a mistake. Our default workflow is to keep our serialized fields private, since these often are intended for designers to tweak in the editor. Making those fields public opens up for all kinds of issues where developers unknowingly might change the values set by design.
     
    Ryiah, Senshi, Casper-Chimp and 7 others like this.
  5. VGMFR

    VGMFR

    Joined:
    Nov 22, 2014
    Posts:
    5
    Hello,

    I've been waiting for this fix for so long now, I'm so glad that you're finally addressing it. Thank you for that.

    1. Highly experienced, with 8+ years of development. I am lead game developer of a successful mobile game company since 2 years now, with hundred of thousands of DAU playing our games.

    2. Mobile hardcore strategy games.

    3. From what I understand, Project Setting, reorderable list is not a fixed at all and is not what we expect from this fix. Same thing for checkbox, this is not satisfying at all.

    "Suppress the Warning by Default" => YES ! This is exactly what all developers are waiting for, just a fix for the regression. Not a workaround that hides the issue.

    4. Assembly Definition Inspector is not satisfying either, as it hides valid cases. Roslyn Analyzer could be a good solution, even if I lack of visibility right now to be sure about it.
    With all my respect, Changing Best Practices is one of the most absurd / chocking thing I ever read on this subject, and I had to read it 3 times to be sure that I was not misreading it. Please don't do that.

    In short: The warning should only be raised in valid cases, and not when [SerializableField] is used. The Unity fix should not hide the issue by suppressing valid cases for this warning.

    Anyway, thank you for working on it, and I hope to finally see this fix asap!
     
    Last edited: Sep 2, 2020
    Ryiah, Reahreic, Ex-Crow and 8 others like this.
  6. GregBahmPersonal

    GregBahmPersonal

    Joined:
    Sep 19, 2017
    Posts:
    2
    I got here from a series of threads complaining about this issue, after finding this issue annoying.
    1. What's your level of unity experience?
      • I've been shipping Unity products for Microsoft for the past 7 years
    2. What's the current project you are working on?
    3. Which solution should we implement for 2018.4 LTS, 2019.4 LTS and 2020.2 based on the list below?
      • Surpress the warning by default. The field will not always have it's default value null. The warning is simply false information.
    4. Which solution should we focus on for new releases of Unity 2021.1 and above, based on the list after the solutions for 2018.4, 2019.4, and 2020.2?
      • Surpress the warning by default. The warning is simply false.
     
    ModLunar, Reahreic, Dextozz and 4 others like this.
  7. APSchmidt

    APSchmidt

    Joined:
    Aug 8, 2016
    Posts:
    3,921
    1. still a beginner, actively learning,
    2. a 2D platformer,
    3. the first solution "Project Setting, reorderable list",
    4. the solution where you "add a Roslyn analyzer to specifically suppress the warning for SerializeField".
    Please, do not modify the best practices, even if you are asked to! :)

    Thank you!
     
    Ryiah, angrypenguin and Xepherys like this.
  8. FlaSh-G

    FlaSh-G

    Joined:
    Apr 21, 2010
    Posts:
    199
    1. 10+ years with Unity, using it in a professional capacity
    2. Games, Unity assets and learning resources
    3. Nothing
    4. Roslyn Analyzer
    I'm extremely confused about this post.
    This is very misleading, as there's a way better way:
    Code (CSharp):
    1. [SerializeField]
    2. private Thing thing = default;
    I am using this all over the place with no issue. Once roslyn allows Unity to just define that [SerializeField] should suppress this warning, that's great, but until then, why would we disable this warning project-wide? Warnings exist for a reason and just disabling them because we don't want to add a little
    = default
    is definitely a very bad idea.

    Edit: Clarification because people seem to misunderstand: I'm not saying that the default keyword is the best and final solution. I'm saying it's the best option until we get programmatic suppression - while just disabling the warning globally or using #pragma are not good ideas.

    For the love of your personal favorite diety, please don't do that. Unity docs are historically full of horrible best practices, please don't add another one. Having a thing publicly accessible from other classes and having it serialized in the editor are two things that should continue to be kept seperate. Sometimes you want things public, sometimes you want things non-public, sometimes you want to have a deserialized value and sometimes you don't. All four combinations exist and have useful application scenarios.

    What I want you to do is
    1. Wait until [SerializeField] can be set up to tell the compiler to suppress the warning automatically. If that's not feasible for this or that LTS version, then do nothing at all.
    2. Recommend to use the default keyword. Don't recommend using #pragma, don't recommend using public just to get rid of a warning.
     
    Last edited: Sep 16, 2020
    idbrii, Ryiah, Plaximo and 12 others like this.
  9. Xepherys

    Xepherys

    Joined:
    Sep 9, 2012
    Posts:
    198
    1. Significant - I've been using Unity since Unity 5.
    2. Ostensibly a puzzler, but have spent much time recently delving into ray-traced visuals and noise algorithms.
    3. Project setting, reorderable list - this seems to be the most balanced option.
    4. Roslyn analyzer is probably my preferred option.

    And just to echo everyone else, making non-standard commentary on best practices is really not great. I love Unity, but the documentation already leaves much to be desired, and for folk learning software development by way of Unity, filling their heads with bad ideas is not going to be good.
     
    disturbedUKR likes this.
  10. jamie_xr

    jamie_xr

    Joined:
    Feb 28, 2020
    Posts:
    10
    1. 8+ years as a professional game developer (5+ Years with unity, since unity 4) , Head of Development at a studio with several shipped unity titles
    2. A VR shooter for PCVR and quest platforms
    3. "Suppress the Warning by default" as others have stated fix for the regression
    4. "Surpress the warning by default" is the best solution. I think "Roslyn Analyzer" and "Reorderable List in Project Settings" are worthy of exploration also.

    I would also like to echo VGMFR's comments. The idea of "Changing Best Practises" to encourage public fields just for serialization purposes is quite honestly ridiculous. It goes against nearly every principle of software engineering. On a related note, I'd suggest that making a field public would automatically NOT make a field serialized by default. My preference would be that in order to make a field serialized, the attribute would required, since the accessibility of a field by code has nothing to do with it's serialization functionality, and it's visibility in the inspector for that matter, They are 3 seperate things. This is my preference and I cannot be alone.

    The fact that this is even being suggested is very concerning to me and my team given we rely on your technology. It's not the thought of this being implemented that concerns me, it's what it might represent, which a great disparity between philosophies.

    Has this option been discussed internally and taken seriously? It would be interesting to have some insight into the thought process behind this suggestion.

    @FlaSh0-G Most half decent IDEs will tell you that it's redundant to initialize a field when the value is it's default value. It's not about being lazy, you are adding something that is a workaround, something that's unnecessary and therefore obsolete.
     
  11. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    5,581
    Both "Suppress the Warning by Default" and "Nothing" works for me.

    Using Roslyn Analyzer sounds like a solid solution, because it seems that's the only option that specifically suppresses the warning for SerializeField.

    The other ideas seem to suffer from side-effects, such as ignoring 0649 for cases other than SerializeField too. I still want to get 0649, just not for SerializeField.
     
    Xarbrough likes this.
  12. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    5,391
    What's your level of unity experience?
    6 years of full-time professional work. 1 shipped game, very close to 2 shipped games.

    What's the current project you are working on?
    Mesmer:
    https://twitter.com/oleivarrudi/status/1301630336561020929
    https://twitter.com/oleivarrudi/status/1301628364197855244
    + doing stuff for https://www.kickstarter.com/projects/ggadventures/girl-genius-adventures-in-castle-heterodyne
    + one undisclosed 2D game project

    Which solution should we implement for 2018.4 LTS, 2019.4 LTS and 2020.2 based on the list below?
    The project settings "pass arbitrary arguments to the compiler" is something I could see being useful in general, rather than just for this instance. It would for example allow studios to add warnaserror for specific warnings or whatever.
    So definitely go for that one!

    Which solution should we focus on for new releases of Unity 2021.1 and above, based on the list after the solutions for 2018.4, 2019.4, and 2020.2?
    The analyzer. That's the cleanest thing, since it targets this specific issue, and doesn't suppress useful warnings. The analyzer should definitely ship as a default package rather than an opt-in thing, as using [SerializeField] private is a best practice.

    Gonna second everyone else on "update best practices" not being the best of ideas. "Tell people to write worse code so we don't have to fix a problem" is not the best plan!

    This would be a big improvement, yes.
     
    Last edited: Sep 4, 2020
    ModLunar, Ryiah, TJHeuvel-net and 4 others like this.
  13. FlaSh-G

    FlaSh-G

    Joined:
    Apr 21, 2010
    Posts:
    199
    I only randomly stumbled upon this :p

    Anyway, it seems that you skipped half of my post... The only decent solution is having the warning suppressed automatically through the attribute. But until we get that, we have to pick between
    1. living with the warnings
    2. add ugly pragmas in there
    3. use default or
    4. disable that warning globally.
    All I am saying is that until we get programmatic suppression, option 3 is the best one. Nothing more. Of course not having to pick any of these band aid solutions would be infinitely preferable.

    Either way, what I originally wanted to say is that I agree with this:
     
    Last edited: Sep 4, 2020
  14. steinbitglis

    steinbitglis

    Joined:
    Sep 22, 2011
    Posts:
    174
    1. CS master, then 9 years of Unity experience as a professional.
    2. Working on projects, yes.
    3. - Project Setting, reorderable list (Useful, but not a solution for this)
      - Project setting, checkbox (If you want ignore all warning writers, then just turn off warnings, or look away from the console, pray a little)
      - Suppress the Warning by Default (No, this is reintroducing an error)
      - Nothing
    4. - Assembly Definition Inspector (Useful, but not a solution for this)
      - Roslyn Analyzer
      - Changing Best Practices (Don't add more hoops now, I'm already a circus animal).
     
    Bip901 and JoNax97 like this.
  15. Rallix

    Rallix

    Joined:
    Mar 17, 2016
    Posts:
    118
    1. What's your level of unity experience?
      About 4 years, a long time hobbyist, and a CS student.

    2. What's the current project you are working on?
      Working on a mid-sized RPG, other than that, small WebGL games from time to time

    3. Which solution should we implement for 2018.4 LTS, 2019.4 LTS and 2020.2 based on the list below?
      I like the reorderable list. It could be useful even for other cases besides [SerializeField], i.e. it's nicer than having a csc.rsp file sitting at the root of Assets folder. I'd suppress CS0649 by default, so that it doesn't confuse new users.
      I also often globally suppress obsolete warnings for some Asset Store assets specifically (because I don't want to re-edit the scripts every time I update the asset), so this Project Settings solution would be nice to have.

    4. Which solution should we focus on for new releases of Unity 2021.1 and above, based on the list after the solutions for 2018.4, 2019.4, and 2020.2?
      Roslyn Analyzer, because it fixes specifically the [SerializeField] false positive, and doesn't hide the cases when the warning is displayed legitimately. I'd perhaps add the analyzers package by default when starting a new project (there's already a lot of "optional" default packages anyway, and this one would be in the category of "fix/improvement" rather than "feature").
      Definitely do not change best practices, simply because making everything public is not the best practice, and it would be unwise to pretend it is just to avoid an annoying incorrect warning.
     
    Last edited: Sep 5, 2020
    angrypenguin likes this.
  16. Detour_Guide

    Detour_Guide

    Joined:
    Jul 9, 2017
    Posts:
    5
    1. What's your level of unity experience?
      11 years of professional Unity development.

    2. What's the current project you are working on?
      Computer vision visualization for autonomous vehicles, and various long-term game passion projects.

    3. Which solution should we implement for 2018.4 LTS, 2019.4 LTS and 2020.2 based on the list below?
      I agree with @Rallix. The re-orderable list would be useful in general, but CS0649 should be suppressed by default. If you don't have the man-hours to complete the re-orderable list for 2020.2, then just turn this warning off until a more robust solution is completed.

    4. Which solution should we focus on for new releases of Unity 2021.1 and above, based on the list after the solutions for 2018.4, 2019.4, and 2020.2?
      Roslyn Analyzer seems like the way to go if it can prevent false positives. I'm unsure on that front. Though I would encourage adding the package to all projects by default. This issue is confusing even for senior devs who might only have some familiarity with Unity. Good developers don't like to disable warnings project-wide, I'm currently working in a very large project with
      Code (CSharp):
      1. #pragma warning disable CS0649
      and
      Code (CSharp):
      1. #pragma warning restore CS0649
      surrounding all Serialized fields in every class. It's a hell-scape.
    This should not even be considered. This is the opposite of a best practice.
     
    Last edited: Sep 7, 2020
    angrypenguin and PraetorBlue like this.
  17. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    595
    Can't believe what I just read.

    Just add Roslyn Analyzer and stop wasting time on anything else.
     
    Dextozz and xVergilx like this.
  18. APSchmidt

    APSchmidt

    Joined:
    Aug 8, 2016
    Posts:
    3,921
    @miniwolf_unity 's proposition was probably a bait, just to see who would gulp it. :)
     
    Kamyker likes this.
  19. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    595
    Dig for bit and there's a fix that probably works for 2018.4+ (works for me in 2020.1)

    1. In project folder create a folder (I've called mine RosalynAnalyzers)
    2. Download https://www.nuget.org/packages/Microsoft.Unity.Analyzers, unzip by changing extension from nupkg to zip.
    3. Copy dll from "analyzers\dotnet\cs" to folder in step 1
    4. Create csc.rsp in Assets folder
    5. Add
    Code (CSharp):
    1. -a:RoslynAnalyzers\Microsoft.Unity.Analyzers.dll
    there
    6. Happy coding

    I guess it works, before:


    After:


    Btw I'm also using great plugin by @tertle that makes analyzers work also with VS as some critical ones are missing like:


    My RosalynAnalyzers folder:
     
    Rallix likes this.
  20. APSchmidt

    APSchmidt

    Joined:
    Aug 8, 2016
    Posts:
    3,921
    For Linux and Mac?
     
  21. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    595
  22. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    2,592
    1. What's your level of unity experience?
      -- Hobbyist since 2015, dayjob worker / developer since 2017.

    2. What's the current project you are working on?
      -- Multiple mobile projects (Unity v2019.1, 2019.2, 2019.3, 2019.4) on the work and a hobby project at home (Unity 2019.4)

    3. Which solution should we implement for 2018.4 LTS, 2019.4 LTS and 2020.2 based on the list below?
      -- Roslyn Analyzer fix or ignore it by default.

    4. Which solution should we focus on for new releases of Unity 2021.1 and above, based on the list after the solutions for 2018.4, 2019.4, and 2020.2?
      -- Roslyn Analyzer fix or ignore it by default.

    Making each field public is extremely bad practice, please stop promoting it in the manual.

    Currently I'm using default initializers for those fields. It was extremely annoying at first to update large codebases for the projects to the "= default style". Now - I don't really care that much. Its basically a muscle memory.
     
    Last edited: Sep 11, 2020
  23. miniwolf_unity

    miniwolf_unity

    Unity Technologies

    Joined:
    Apr 10, 2018
    Posts:
    103
    I want to thank everyone here in the thread for adding their voice to this situation. It is one of the most up-voted issues we have seen in my team for a while. It was opened quite a while back. It was closed. Re-opened by public demand. We took good care to ensure that we fix this issue in the right way this time. We do not want another downfall down the line.

    Here is the solution that we are going with. I try to sum up how it solves the problem and what it means for different scenarios.

    For 2018 LTS, 2019 LTS, and 2020 LTS we will be adding the reorderable list inside the project settings window. This will be landed as fast as possible, as you have waited enough for a solution to this problem.
    How does this solve the problem users are facing currently?
    By default add the suppressor to the list. This gives new users, beginners, those who just want things to work, a clean experience. We are not showing them a warning that is not actionable and leads to confusion.
    For the advanced user, who understands the implication, you can remove the suppressed warning. The list is completely modifiable. You can add and remove any compiler arguments you want to pass project wide (to all assemblies).

    ---------------------------------
    Going forward we will be adding Roslyn suppressors in package that will be shipped default with projects. These can be toggled off as any other package in Unity. It is not known as of yet when this project will be prioritised.
     
    Ryiah, JvanE, Dextozz and 6 others like this.
  24. APSchmidt

    APSchmidt

    Joined:
    Aug 8, 2016
    Posts:
    3,921
    Hi,
    Forgive me for the dumb question but where will the "Roslyn suppressor in packages" be? I hope they won't be added to the Visual Studio and Rider editor support packages because I'm not using them. :)
     
  25. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    5,391
    Sounds like it's own package in the package manager.
     
  26. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    595
    Oh it seems like it's working for me as I've updated C# compiler manually. It is already updated in Unity 2020.2 so it will work out of box from that version.
     
  27. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    13,510
    1. What's your level of unity experience?
      Professional, working with it for a wide variety of projects since v1.6.

    2. What's the current project you are working on?
      Open world exploration game right now, but I've done all sorts.

    Heck no, not this one. I'd be up for a review of how stuff gets exposed to the Inspector*, but officially recommending against the use of [SerializeField] in favour of something that gives you less control would be a step backwards from my perspective.

    Just because something is available in the Inspector does not mean I want other scripts to be able to change it. And wanting scripts to access stuff does not mean I want to expose it to designers. So, please, don't advocate for combining those things!

    * Particularly when it comes to properties, which are not exposed by the default Inspector at all.

    I like this one. However, since you're making a UI anyway, it'd be neat to go one step further and also add a list of common stuff that we can tick / untick and have it add them into the argument list for us.

    I like this one, with the same addition as above - a UI element to add/remove common ones.

    In the future, when you get to the ASMDEF one, there should be a button in the UI which brings up the global list in the project settings, too.

    Question... why does it matter that it's a "reorderable" list?

    Edit: As a follow up, I'm really glad to see so many people here strongly advising against the proposed change to best practices.
     
    Last edited: Sep 14, 2020
    ModLunar, Ryiah and Rarepops like this.
  28. Rarepops

    Rarepops

    Unity Technologies

    Joined:
    Sep 5, 2019
    Posts:
    33
    I don't think the "Reorderable" part will make a difference per se. It would just be a list basically :)
     
    ModLunar and angrypenguin like this.
  29. steinbitglis

    steinbitglis

    Joined:
    Sep 22, 2011
    Posts:
    174
    Hmm. All lists are reorderable per se... it's just that Unity thinks that reordering some of them should be difficult, I think.
     
  30. Rarepops

    Rarepops

    Unity Technologies

    Joined:
    Sep 5, 2019
    Posts:
    33
    It's more that historically some of those lists were not reorderable, which could be annoying to work with in some cases.
     
  31. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    595
    Ehh... That list "solution" is as good as adding csc.rsp to default project template.

    Hopefully there will be API to add something to the list then making package with Microsoft.Unity.Analyzers and
    a:Packages\com.bestname\Microsoft.Unity.Analyzers.dll
    will take 10 mins.
     
    YurySedyakin and Rarepops like this.
  32. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    101
    1. 3 years now, 1 year DIY and 2 years education primarily using Unity.
    2. Can't say (confidentiality and all that).
    3.
    I completely agree, I'm using a csc file right now in every project and it always has at least 0649 in it. The interface would have been nice when I was just a wee lad stumbling with this issue (who am I kidding, I'm still a wee lad). However, the more hardcore programmers among us should be able to remove the nowarn and this seems the best option.
    4. I've got no opinion on this, I haven't dabbled in dll's too much (I mean I have, but not like that).

    Fire the guy that suggested the documentation change, how dare he.
     
    YurySedyakin likes this.
  33. lucasvarney96

    lucasvarney96

    Joined:
    Sep 18, 2020
    Posts:
    1
    1. I have been working with Unity for about 3 years, but I have been programming for much longer (about 9 years total.)
    2. A top down shooter with a built-in level editor.
    3. Reorderable list, but Roslyn analyzers would be preferable if possible
    4. Roslyn analyzer
    I think we should avoid this at all costs. Public fields aren't a good or safe practice, and can be especially dangerous to new programmers. The recommended practice should be to [SerializeField] a private field, and then expose it in a property if necessary.
     
  34. Dmitry-Pyalov

    Dmitry-Pyalov

    Joined:
    Dec 13, 2011
    Posts:
    118
    1. CS background. 13 years of C#. 7 Unity projects launched on almost all available platforms.
    2. 2D game not yet announced
    3. Nothing. Visual Studio showed those warnings since the beginning. #pragma works fine
    4. Roslyn or nothing. We never researched Roslyn, but all other options sound bad.
     
  35. emerge-sjh

    emerge-sjh

    Joined:
    Oct 16, 2020
    Posts:
    9
    1. What's your level of unity experience?
      15+ years
    2. What's the current project you are working on?
      Some stuff I can't talk about lol
    3. Which solution should we implement for 2018.4 LTS, 2019.4 LTS and 2020.2 based on the list below?
      Setting a default value, like the warning suggests (and is good practice in general, imho.
    4. Which solution should we focus on for new releases of Unity 2021.1 and above, based on the list after the solutions for 2018.4, 2019.4, and 2020.2?
      Roslyn analyzer? sure. But imho I think people are complaining about a completely valid warning and they're just too lazy to initialize the variables.
     
  36. vharutyunyan

    vharutyunyan

    Joined:
    Sep 4, 2019
    Posts:
    2
    1. Unity experience - 4 years
    2. Working on several 2D mobile games as a contractor
    3. Suppress common warnings checkbox. I think everyone was fine before the change that caused those warnings to appear.
    4. Roslyn analyser.
     
  37. McDev02

    McDev02

    Joined:
    Nov 22, 2010
    Posts:
    646
    First I always make my Inspector fields private as this is simply a quick way to define data that I would otherwise store in other serialized ways, such as scriptable objects or JSON files. But for small projects this is just a ridiculous overhead. They will only become public if they have to be accessed by another class.
    1. Hobbyist for 10 years, professional for 5 years
    2. Too many... Rather small Web, VR and AR apps for marketing purposes
    3. I can not think of additional warnings that I want to suppress currently, so the Suppress common warnings checkbox checked by default should be fine. If there is still the option to simply add a csc.rsp file, I think that serves everyone and does not clutter the Player settings even more.
    4. Abstention
     
    Last edited: Nov 18, 2020
  38. Ziflin

    Ziflin

    Joined:
    Mar 12, 2013
    Posts:
    93
    I agree with @McDev02 that suggesting that fields have to be public to be editable is silly. Proper class design should not be dictated by this issue.

    1. Professional Game Engine Developer for ~20 years.
    2. Unity Diablo-ish like RPG.
    3 & 4. Asmdef makes the most sense to me. This should be a per-library (assembly) setting and not dictated by a global setting.

    Ideally this would be solved by an attribute that C# compilers recognize to treat the variable as reflection-initialized. Then the [SerializeField] attribute could derive from it and we could stop having this insanely long discussion over something all C# compilers should support. For instance, how does the [DataMember] attribute work on private fields without a similar issue?
     
    Last edited: Nov 18, 2020
  39. imangitarrowood

    imangitarrowood

    Joined:
    Feb 18, 2016
    Posts:
    1
    1. 5 years Unity, 15 years game dev, tech director at a mid-sized studio
    2. Unannounced mobile game
    3. Agree with Ziflin, needs to be per assembly
    4. Roslyn Analyzers solution would be better in the long term, targeting the specific case of the issue instead of suppressing a useful warning globally or even per assembly

    And I'll add my voice to the chorus of absolutely do not make public fields a best practice.
     
    Last edited: Nov 18, 2020
  40. Rarepops

    Rarepops

    Unity Technologies

    Joined:
    Sep 5, 2019
    Posts:
    33
    Hi, a little update on this.

    We have landed fixes all the way back to 2018.4!

    For 2018.4 and 2019.4 we have restored the previous behaviour where we ignore CS0649, without a way to change it.
    However, from 2020.1 you have a checkbox to ignore (or not) the previously hardcoded CS0649 and CS0169 in the PlayerSettings.
    From 2020.2 you have both the checkbox mentioned above AND a re-orderable list in which you can choose to add any compiler arguments from https://docs.microsoft.com/en-us/do...erence/compiler-options/listed-alphabetically :)
     
  41. Ziflin

    Ziflin

    Joined:
    Mar 12, 2013
    Posts:
    93
    @Rarepops Is there some reason this is a project wide setting? What if there are 3rd party packages that require different compiler arguments?
     
  42. Rarepops

    Rarepops

    Unity Technologies

    Joined:
    Sep 5, 2019
    Posts:
    33
    I am not sure what you mean, this mechanism won't prevent that from working, it's additive. If a package wants some specific compiler arguments, there is always the csc.rsp way :)
     
  43. Ziflin

    Ziflin

    Joined:
    Mar 12, 2013
    Posts:
    93
    Ok, just wasn't 100% sure that this wasn't going to replace the csc.rsp file.
     
  44. Rarepops

    Rarepops

    Unity Technologies

    Joined:
    Sep 5, 2019
    Posts:
    33
    Nono, it's an alternative and it is additive :)
     
  45. Simpowitch

    Simpowitch

    Joined:
    Nov 13, 2018
    Posts:
    6
    Thanks the [diety of your choice]! Finally, we have asked for this since the issue was closed a couple of years back. Nice to see that you guys are listening!
     
    Rarepops and FlaSh-G like this.
  46. swedishfisk

    swedishfisk

    Joined:
    Oct 14, 2016
    Posts:
    28
    I'm very keen to try this out, I have a project on 2020.1.8f1 and I can't find anything under Project Settings -> Player regarding disabling these warnings. Do you have to redownload the editor or how does this backporting work?
     
  47. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    13,510
    This got me curious. I could have sworn that there were other occasions where this had come up, but I made a new project and spent a couple of minutes trying to get a warning (not necessarily this one) on an initialised but otherwise unmodified variable, and I couldn't. Maybe I didn't try hard enough?

    Anyway, I'm the kind of person who likes my code to be explicit, so I can't imagine that I'd have got into the habit of leaving stuff out without some reason. But I started in Unity 10+ years ago now, so I can't fully remember exactly when or why I got into this particular habit.

    So I asked myself why I care about that warning if I could have been getting rid of it both trivially easily and in a way that suits how I code anyway. And I found an answer pretty quickly: if a value is a serialized field, then the explicit initialisation value's only purpose is to provide a default for the Inspector. I'm pretty sure I'm in the habit of leaving them blank when there's no sensible default to reinforce the idea that "this comes from elsewhere".

    That probably itself got reinforced back when I was first learning Unity. I remember more than one occasion where I was wondering why changing a value in my code had no effect... and it was because Unity had serialized the first value I had in there, and been reusing it ever since. Leaving it blank meant I wasn't tempted to change it there. It also got rid of a thing I had to remind myself was redundant. It's one less opportunity for me to make a mistake while I'm writing code.

    It's not exactly a big deal. I'd be keen to know how other dev environments with similar data injection approach this stuff. Do programmers just get used to initialisation values being defaults?
     
    AriyaSD, firstuser and Novodantis like this.
  48. Novodantis

    Novodantis

    Joined:
    Nov 12, 2009
    Posts:
    95
    1. Long time user; since Unity 3, I think
    2. Too many to mention, but mostly small indie games these days
    Seems the other points are already resolved, but just wanted to offer a counter perspective to calls for serialization to be explicit.

    I can see the appeal from a consistency point of view, but I think it's best left as is. The Old Gits of Programming can sometimes forget how much of this complexity we have assimilated, but there is a very approachable simplicity to Unity that I can still vividly remember from getting into it. Public variables automatically showing in the inspector often works because-- yes, while there is no hard connection, there is often a correlation. It does depend how rigid you are with public variables. If you are the sort of coder that basically never uses them, then you effectively have what you want anyway: only what you serialize will be shown in the inspector.

    But if this were to be true for all variables it would bloat simple scripts, add more stumbling blocks in the very earliest path of newbies and not really accomplish anything new, given that [HideInInspector] exists for the rare event I want another class to access a value and not a designer. I'm all for clean, optimal code; but there's something to be said for readability and reduced bloat, too. Unity's approachability is one of its strengths.

    That said, I totally agree with the consensus here that the Unity docs should not encourage using public as a means for inspector visibility. It's just that it's a reasonable default assumption, is all.
     
  49. firstuser

    firstuser

    Joined:
    May 5, 2016
    Posts:
    93
    If you use Rider it just lets you know "hey this is serialized" and you don't have any confusion. It will even help you find which scene/prefab or whatever it's serialized in.
     
    Last edited: Dec 10, 2020
    xVergilx likes this.
  50. Rarepops

    Rarepops

    Unity Technologies

    Joined:
    Sep 5, 2019
    Posts:
    33
    You can see in the image below where it is. You're probably on a version that's older than the one where the fix landed. Try updating your Unity from 2020.1.8f1 to 2020.1.17f1 :)
    upload_2020-12-11_16-54-47.png
     
    swedishfisk likes this.
Thread Status:
Not open for further replies.
unityunity