Why define a getter before the installer (coding convention)
I understand that this question is a bit silly, so I apologize in advance if this is not relevant or constructive.
Why in C # is it the standard * convention for defining properties with a getter before the setter? For properties with both, you are almost always going to use a setter before the getter so that it is in the correct state. So it seems a bit backward to me that we define a getter first.
Also, the installer usually has some sort of validation logic that the getter doesn't need. It would not be easy if this logic was ahead of the getter to understand more clearly how property should behave. For example:
public decimal Price
{
get { return _price; }
set
{
if(value < 0m)
{
throw new ArgumentOutOfRangeException();
}
_price = value;
OnPropertyChanged("Price");
}
}
Is the code in the setter much more interesting than the recipient if it has no priority and is determined first?
* I know there are no rules with these things, but pretty much every property example ever defines a getter before the setter.
source to share
Because it is better to give than receive.
On a more serious note, I'm assuming that whoever wrote the snippet (or whatever the auto-gens property code in VS) subconsciously chose this order.
Then, since the rest of us are just sheep for this pioneer shepherd, we followed without question.
Up to you.
You ask our once great shepherd, anarchy can only arise. Commit your code and run for hills.
source to share
The getter is usually much shorter (usually a one-liner), so prefixing it allows for better viewing, just as you would prefer it:
if (condition)
{
// Short code
}
else
{
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
}
instead of this:
if (!condition)
{
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
// Long code
}
else
{
// Short code
}
And more than that - only because.
source to share
The order of the getter and setter is completely out of order, I think the reason for the convention is the Visual Studio property snippet that generated the properties this way (getter before setter). So after using this snippet several times, this ordering has become an unwritten, shameless practice for most coders (myself included). This, of course, doesn't explain why the VS designers implemented this snippet this way. My opinion: they do not know this, and they are not interested in it, or maybe because r occurs earlier in the English alphabet than in. Who in the world cares so much anyway?
source to share
I think consistency is important here. While in your example the setter is "more interesting", I don't think it necessarily happens in most cases. Indeed, one of the reasons auto-properties are so useful has to do with the frequency with which get and set code is simply read from / written to a private field without any other processing, in which case neither of them is "more interesting".
In your own projects, you can of course put them in any order you like, and if you decide that the setters should come first based on "importance" or for some other reason, you can completely do that. However, given the widespread nature of the pre-installation getter convention, if you plan on sharing your code, it would be wise to follow the convention for the sake of those that you might need to read or change in the future.
source to share