Discuss usage of properties vs fields

[tintoy]

Context:

#54 (comment)

CC: @DoctorKrolic

[DoctorKrolic]

Well, my main argument as I already mentioned is the following: it makes clearer separation between private state and public API. Since if following default .NET code style, typing _ in the editor should bring all private fields, while right now in order to distinguish private and public members I need to look and completion icon in VS or even go to definition if property icons are the same for private and public members like in VS Code. And, if it matters, replacing properties with fields makes compiler generate less code, so resulting assembly is slightly smaller in size

[tintoy]

That's a a pretty decent argument - I think my argument was around usage but I'll need to go dig it up. For what it's worth I'm leaning towards agreeing with you for the most part (except where it is meant to be accessible by derived types).

[DoctorKrolic]

except where it is meant to be accessible by derived types

Yeah, these should stay as protected properties, it's a standard practice

[tintoy]

Ok, have finally had time to put my thoughts in order on this.

I think mostly I've been using properties for things representing common facilities because I usually put those in a base class (to ensure that all components of a given type consume their dependencies consistently). And probably wound up using properties elsewhere to be consistent (if some components have Log.Information(xxx) and others have _logger.Information(xxx) then visually it's not as easy to spot, but this isn't a particularly big deal in the scheme of things).

But now that I remember why I did it, I don't feel that strongly about it, so I'm fine with you switching to fields if you want to.