Incorrect icons for Unity handled members

[nkAlex]

Displaying Unity icons for Unity-handled stuff is a neat feature, though currently some of the icons seem to be placed incorrectly — for example, icons are displayed for public static fields which are not serialized by Unity at all.

Members handled by Unity (that I know of so far) are:

• Unity's implicit methods (Start(), Awake(), etc. + their IEnumerator versions);
• All non-static public fields not marked with a [NonSerialised] attribute;
• All non-static public or private fields marked with a [SerializeField] attribute;
• Methods marked with a [RuntimeInitializeOnLoadMethod] attribute;
• Classes marked with an [InitializeOnLoad] attribute.

[citizenmatt]

Brilliant list, thanks! I'm not a Unity expert at all (I'm coming from the ReSharper side of things 😄) so this kind of detail is absolutely perfect! I'll get this updated ASAP. Thanks!

[nkAlex]

I'm pretty new to Unity myself, might have missed something :)

[citizenmatt]

Well, between us all, I'm sure we'll get there eventually :)

[nkAlex]

A little something I randomly remembered: sometimes ReSharper is advising to make certain fields readonly, but if those fields are intended to be serialized by Unity, that will lead to editor/runtime errors. So, it would be nice to suppress those suggestions for serializable fields and advise marking such fields as readonly as errors/warnings instead. Does not affect anything else which is not related to serialization.

Serializable fields are:

• All non-static public fields not marked with a [NonSerialized] attribute;
• All non-static public or private fields marked with a [SerializeField] attribute;

---

And another pretty specific serialization nuance I only came upon when modifying code for an already compiled game — the order in which serializable fields are listed in a class matters, so it would be nice if one could "lock" this order from accidental changes (by ReSharper's code cleanup, for example). I know it's possible to create specific sorting rule set for members in ReSharper's options, but still, pretty easy to accidentally miss :)

[citizenmatt]

I think I'm not going to add the highlight to methods marked with [InitializeOnLoadMethod] and [RuntimeInitializeOnLoadMethod]. I think it best to save the highlight for "magic" type members - fields or methods used implicitly. If it's got an attribute slapped on it, it's fairly obvious that it's being used by Unity. But serialized fields, event functions and the static constructor in [InitializeOnLoad] classes aren't obviously being used.

[nkAlex]

Makes sense :) Though in this case I was thinking more like treating those methods as used implicitly so that ReSharper won't mark them as unused (pretty much what the [UsedImplicitly] attribute does)

[citizenmatt]

Yeah, that's already handled by the external annotations - [InitializeOnLoadMethod] and [RuntimeInitializeOnLoadMethod], etc. are all marked as [MeansImplicitUse], so the things they're applied to are marked as in use.

A similar thing happens in code for the serialized fields, which affects how the read only suggestion works - I tell R# that the fields are implicitly assigned, but it doesn't know when that happens so doesn't apply the read only suggestion (which requires the only assignment to be in the constructor).

Reordering is an interesting one. I'll open a new issue for that - #88