Suggesting solutions for SerializeField warning

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.

 

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.

 

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.

 

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!

 

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?
   • Dynamic 365 Remote Assist for Hololens 1, 2, and Mobile
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.

 

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!

 

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.

 

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.

 

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.

 

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.

 

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.

 

I only randomly stumbled upon this

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:

 

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).

 

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.

 

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.

 

Can't believe what I just read.

Just add Roslyn Analyzer and stop wasting time on anything else.

 

@miniwolf_unity 's proposition was probably a bait, just to see who would gulp it.

 

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:

 

For Linux and Mac?

 

Not sure, there's also mac version you can try to build from https://github.com/microsoft/Microsoft.Unity.Analyzers

 

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.

 

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.

 

Sounds like it's own package in the package manager.

 

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.

 

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.

 

Hmm. All lists are reorderable per se... it's just that Unity thinks that reordering some of them should be difficult, I think.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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

 

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?

 

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.

 

@Rarepops Is there some reason this is a project wide setting? What if there are 3rd party packages that require different compiler arguments?

 

Ok, just wasn't 100% sure that this wasn't going to replace the csc.rsp file.

 

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!

 

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?

 

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?

 

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.

 

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.