UnityEngine.Object properties when serialized have "m_" prefix. Why?

Earlier I was trying to write a function that would return the relevant MemberInfo for a SerializedProperty (using propertyPath and targetObject), but I ran into a problem when I realized most (all?) of UnityEngine.Object properties when serialized are prefixed with "m_".
I figured there must be some really well hidden properties with the "m_" prefix which while never directly accessed by the user, are there internally, but using reflection it appears they don't actually exist.

I want to know what's happening under the hood. I've looked at the decompiled Unity code and found nothing of note.
Pertaining to my function, I suppose I could check each property, if the container type has the namespace UnityEngine then correct the property name accordingly.
However I assume there's a more elegant solution.

Anyway, I'm really just curious about this "m_" business. What's the deal?

 

It means a member variable, AKA a private one. (Probably something a little more specific than that, but eh)
https://en.wikipedia.org/wiki/Member_variable

I think it used to be standard to prepend variables in programming with this but its almost never used these days when developing with Unity

 

Sorry, I forgot to make this clear - I know what "m_" means as a convention for naming variables, my question is why does a variable like Renderer's "materials" becomes "m_materials" when serialized?
I'm not sure if this behaviour occurs in all UnityEngine serializable classes, but I assume so.
I've also noticed there's almost no reference to the variable m_materials (or m_anything) in the decompiled code, except for when referring to a SerializedObject's property.
It appears from my POV there are a vast amount of hidden variables that these m_ variables refer to, but they aren't visible through reflection... or - for some reason - Unity prefixes every variable with m_ when serializing a builtin object (anything that uses UnityEngine namespace).
It just strikes me as very strange behaviour and I can't see the root of it.
This is Unity though... common sense doesn't get you very far here.

 

I saw these "m_" variables in UI source code, a lot. They are fields whereas the ones without "m_" are properties. I believe Unity's serializer doesn't serialize properties and thus, the "m_" fields are serialized instead (the reason I believe that is that we can't see properties in Inspector without a custom Editor script).

While scripting, we are not allowed to change "m_" fields directly as a change to that field might require some other field changes or internal function calls. Therefore, we change properties instead which handle these "other changes" automatically.

 

from Unity Doc - https://docs.unity3d.com/ScriptReference/SerializedObject.html
to see their paths - to see their serialized names of any field are showing in Inspector