C# class property definitions

Question

Will I create any problems if I make all my class properties structure members like the following code does?

 private struct Properties { public int p1; public int p2; } private Properties P; public int p1 { get { return P.p1; } set { P.p1 = value; } } public int p2 { get { return P.p2; } set { P.p2 = value; } }

I did the analogous thing in VB for years, but then speed was not important. Now I am just getting started with C# on real time projects where speed matters. Thanks for any feedback!

What is the supposed advantage to that extra layer even in VB? — Ňɏssa Pøngjǣrdenlarp
– Ňɏssa Pøngjǣrdenlarp, Commented Nov 20, 2015 at 18:13
"Will I create any problems" - Well, it makes the code more complex for no discernible reason. Complex things are more likely to fail than simple things. — David
– David, Commented Nov 20, 2015 at 18:16
What you're suggesting is essentially what's going on when you use the shorthand. You just don't see the instance variable (because you really don't need to.) The only reasons I know to do it your way is if you either have to do some sort of computation during the get/set, or you need to do some sort of range validation. — Duston
– Duston, Commented Nov 20, 2015 at 18:18
You might manage to defeat the compiler's normal inlining of property access: Field vs Property. Optimisation of performance, although the compiler people have included a lot of clever optimisations. What were the results of your tests? — Andrew Morton
– Andrew Morton, Commented Nov 20, 2015 at 18:54

wingerse · Accepted Answer · 2015-11-20 18:23:22Z

10

Yes. The problem will be unnecessary code. You could just shorten your code like this, and it will still function the same:

public int p1 { get;set; } public int p2 { get;set; }

If you wanted to set breakpoints on getter or setter, you could use a backing private field like so:

private int _p1; public int P1 { get { return _p1; } set { _p1 = value; } } private int _p2; public int P2 { get { return _p2; } set { _p2 = value; } }

edited Nov 20, 2015 at 18:23

answered Nov 20, 2015 at 18:16

wingerse

3,8371 gold badge33 silver badges67 bronze badges

Sign up to request clarification or add additional context in comments.

1 Comment

OldRoboCoder Over a year ago

I did this for the sake of sanity. I had classes with hundreds of properties. After a month I'd have to add more in. Using structures let me logically group them. I made a code generator with a properties table. I'd add properties to structures then generate all the code including utility methods, like to clear all values in a group, or import field values from a table, etc. Also, some property groups would be copied to other classes. Execution speed was unimportant (end of day batch processing). Coding ease was. But it may all boil down to personality. I tend to box an label a lot.

leonard_deutsch · Accepted Answer · 2015-11-20 18:36:36Z

Honestly, I don't think your approach will create any problems. Speed and memory are definitely not an issue if you have one small extra struct with your properties - unless you are running your program on some device with just 64K Ram or so but I assume you don't.
So for your question - if you know what you're doing and accessing the right struct variables, then your code will be just fine.

However, as mentioned above, your approach is far from best practice.
C# is a language that uses either Auto-Properties or Properties with underlying backing fields extensively and it is considered best practice and also best maintainable if you follow this structure.

Properties also have a lot of neat advantages - further information under this link:
MSDN Property Tutorial

So, in summary, your approach is not necessarily wrong or slow, it is simply not best practice. And because we encourage best practice, I'd encourage you to not use your approach.

Collectives™ on Stack Overflow

C# class property definitions

2 Answers 2

1 Comment

1 Comment

Hot Network Questions