Suggesting solutions for SerializeField warning

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.

 

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?
   • Zombie Cure Lab
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.

 

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.

 

Has anyone got it working? I get bunch of errors when trying to use it in official way instead of csc.rsp.

 

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