Search Unity

  1. Unity 2020.2 has been released.
    Dismiss Notice
  2. 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.

  1. bibbis

    bibbis

    Joined:
    Dec 5, 2016
    Posts:
    33
    1. 6 years experience, 3 years professional.
    2. VR art exhibition.
    3. Suppress the Warning by Default
    4. Roslyn Analyzer - but include the analyzer package that specifically suppress the warning for SerializeField by default

    Honestly this makes me really irritated so I'm gonna rant.
    How can you possibly suggest changing your recommendation for best practices in the documentation to say that A FIELD SHOULD BE PUBLIC IF YOU WANT IT VISIBLE IN THE INSPECTOR in order to hide a warning message?
    That is absolutely insane.
    DO NOT encourage people to use public variables.
    Please, we already have such a problem with every creator of Unity tutorials teaching people that you should make stuff public just to see it in the inspector.
    PLEASE don't start to officially encourage that as well!

    When it comes to the warning itself I don't even see why this exists.
    When you add the [SerializeField] attribute you are exposing a private variable so that you can edit it in the inspector.
    If you are exposing a private variable to the inspector without any intention to actually edit it in the inspector then you are doing something wrong, so the [SerializeField] attribute really should disable the CS0649 warning for that field.

    If you just want to make Unity serialize the field for you but keep it private and invisible, you can mark your private variable with both [SerializeField] and [HideInInspector].
    Here there can be a debate whether or not you should give users a CS0649 warning about their field, if they don't also initialize it to "= default".
    But as it stands right now I think it's just plain misleading to keep the CS0649 warning.

    One of my favorite things about C# is that variables are actually automatically initialized.
    An int will be 0 until you set it to something else.
    So, being forced to create variables like this:
    [SerializeField] private int myInt = default;
    and adding the blasted "= default",
    every.
    single.
    time.
    in order to disable an annoying warning is just counter productive.
     
  2. Hosnkobf

    Hosnkobf

    Joined:
    Aug 23, 2016
    Posts:
    867
    1. What's your level of unity experience?
      • Lead Developer (Senior). ~8 Years Unity; ~15 Years pofessional game development; ~22 Years hobby game development
    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?
      • Suppress the Warning by Default
        Nobody want to see a warning that a serialized field is not assigned ever! It doesn't make sense to give people a choice here since even if there where values assigned, they would most probably be overidden by the serialized data.
    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?
      • Suppress the Warning by Default
        Same reason as above.
    However, I find the assembly definition inspector a good addition in general. I would combine this with the project settings: Define additional compiler arguments in the project settings which are used for all assembly definition files if not overwritten. Allow assembly definition files to override the poject wide compiler arguments.
     
  3. Rarepops

    Rarepops

    Unity Technologies

    Joined:
    Sep 5, 2019
    Posts:
    33
    Yes we have that now, however it will be treated in an additive way (global + local). If you want a global with exceptions, the way it would work is you would have to create local rules which define the behaviour you want and remove the ones in Player Settings (global).

    The workflow of adding a global rule in the Player Settings then ignoring it seems a bit awkward, because in the end you'd still need to specify to ignore the rule in places you don't want, versus just specifying what you want, where you want it.

    Does that make sense?
     
  4. Hosnkobf

    Hosnkobf

    Joined:
    Aug 23, 2016
    Posts:
    867
    Hmm... probably this is enough... but I am not sure. Maybe a third party asset would require very specific compiler arguments while certain other arguments would break the asset.
    In such a case it would be better to replace the global settings rather than adding to them. Maybe a checkbox "Ignore Global Compiler Arguments" in the asmdef would be helpful for such cases.

    However, there is no specific scenario I can imagine right now where such an option would be needed. So, maybe always just adding arguments is good enough.
     
  5. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    574
  6. TJHeuvel-net

    TJHeuvel-net

    Joined:
    Jul 31, 2012
    Posts:
    566
    1. What's your level of unity experience?
    10 years unity experience
    1. What's the current project you are working on?
    Large AAA-ish online multiplayer shooter

    Whatever you do, do not do this. This goes against any programming guideline, for example the Microsoft C# guideline on Access Modifiers. Public fields should be avoided as much as possible, i encourage everyone in our team to use SerializeField for private serialized fields. I'd rather live with the warning than not having private serialized fields.

    Currently we use the csp file as a workaround
     
unityunity