#properties in c#

1 messages · Page 1 of 1 (latest)

glacial axle
#

properties bad / properties good

mighty cave
#

because you can just modify a public variable. the language gives you that feature by default

glacial axle
#

yeah the argument their making is that its not tidy and can lead to unintended uses of that public field

mighty cave
#

as a convenience. it also is more legible when doing certain things like vector math, to not be calling .getX() every time, instead of just .x

fading moth
#

you can modify a property as well with the same syntax

mighty cave
glacial axle
#

yeah my issue with "encapsulate everything with a property" is that its simply just more verbose. more lines for the same functionality

fading moth
#

same amount of lines

mighty cave
#

we don’t measure in # of lines, but legibility

glacial axle
#

if youre saying i should do public int thing {get; private set;}

fading moth
#

link to what you mean by legibility

glacial axle
#

lol

#

its hard to read "Source?"

#

but anyway

fading moth
#
public float f;
public float f1 { get; set; }
thick wedge
mighty cave
#

some things should have an extra layer of protection, because you really don’t want anything to fuck with it.

#

and that is ok

#

not everything needs that by default

fading moth
#

but having it by default is a good practice, consistent, explicit

valid valley
glacial axle
#

thats if i need something to only be read, and not written. but if i need something read and written, (which is VERY often the case) then the field is faster

thick wedge
#

You don't want to make bunch of diffs by changing field into property

#

Faster.. for what?

mighty cave
#

i thought that is what we are arguing about

thick wedge
#

Faster to write the code?

glacial axle
#

yes

#

faster and fewer characters on screen to read

thick wedge
#

Set up your IDE snippets sir

glacial axle
#

look im not arguing against properties when theres encapsulation necessary. but im just defending the idea that public fields are okay in many circumstances too.

#

if i weren't part of a team that already had standards in place against that

mighty cave
#

I’m also not arguing to make everything needlessly public. But if you want something to be public… just make it public.

#

and use it

thick wedge
#

Honestly I think this argument only exists because Unity's serialization rule, they got comfortable with using public field

mighty cave
#

I have this looming feeling of doom. Where discord says someone has been typing for a while, and you know a lot of keys have been pressed.

valid valley
# mighty cave i thought that is what we are arguing about

Properties are members which are accessed using the same syntax as fields (e.g. .x for get .x = whatever for set), but those operations can be individually implemented or have different levels of access, etc. It's a field-like interface with a lot more flexibility and control - the ability to do things with it which you might think to use a method for, without needing to create a method, or use method syntax

mighty cave
#

you mean to assign different levels of permission to read and write?

valid valley
#

Sure that's one use-case. Like this is an "automatic property" for which C# will create a hidden backing field, with different levels of access per operation:

public float x { get; private set; }
#

Executing validation logic on an assignment is another common use-case - which, if you were just using fields and methods - would force you to switch to a method

glacial axle
#

can we agree that

public int x { get; set; }

is functionally identical to

public int x;

just with more text on the screen?

mighty cave
#

to be fair, read access is not usually what is contended. The big thing is write access

#

and if I don’t want to give write access, that shit is going private with a .get() function

glacial axle
#

but you might say"oh what if x is an angle? wouldnt you want to validate the write access before... yadda yadda" and to that i say YES you would. but only then would you turn this field into a property and validate the writes

#

its about not writing code until you actually need it.