All of the caveats basically boil down to "if you need to access the private backing field from anywhere other than the property getter/setter; then be aware it's going to have a funky non C# compliant field name".

In the EF Core and Automapper type of cases, I consider it an anti-pattern that something outside the class is taking a dependency on a private member of the class in the first place, so the compiler is really doing you a favor by hiding away the private backing field more obscurely.

▲

pwdisswordfishy 13 hours ago | parent | next [-]

I'm surprised there isn't something pseudorandom thrown in for good measure – like a few digits of a hash of the source file.

▲

Radle 10 hours ago | parent | next [-]

The trick with using characters which by definition are not allowed inside variable names, "<" and ">", should be sufficient no?

▲

kg 9 hours ago | parent | prev [-]

I believe the reason for this is that it would break deterministic builds.

▲

kgklxksnrb 9 hours ago | parent [-]

dotnet build is’t deterministic as default. Never has been.

	▲	tomnipotent 4 hours ago \| parent [-]
		Except deterministic builds have been the default since 2015?

▲

materialpoint 12 hours ago | parent | prev [-]

Serialization is a pretty good cause.

	▲	NetMageSCW 10 hours ago \| parent [-]
		Serialization shouldn’t be dependent on the name of the backing field.