Why properties shouldn't return arrays...?

Question

0.00/5 (No votes)

See more:

In a program I hve to return a multi-dimensional array, so that I could use it in another class.
One solution is declaring that array as static...
Another way is to declare a property which through GET-SET Property returns the array through its GET property...

When I am doing so the compiler is giving me warning that -- property shouldn't return arrays...Why...?

What I have tried:

Declared in Child Class....
public string[,,,] Fields
{
get { return row;}
}
row is the multi-dimensional array....

Posted 10-Jul-20 5:00am

Member 12712527

Updated 10-Jul-20 5:22am

Add a Solution

2 solutions

Solution 1

All you have to do is learn how to use google.

CA1819: Properties should not return arrays - Visual Studio | Microsoft Docs[^]

Posted 10-Jul-20 5:21am

#realJSOP

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

OriginalGriff · Accepted Answer · 2020-07-10T05:22:00

Solution 2

Start with the error message documentation:
CA1819: Properties should not return arrays - Visual Studio | Microsoft Docs[^]
It explains:

Microsoft:
Arrays returned by properties are not write-protected, even if the property is read-only. To keep the array tamper-proof, the property must return a copy of the array. Typically, users won't understand the adverse performance implications of calling such a property. Specifically, they might use the property as an indexed property.

Copying an array is a big job, and can cause quite a performance hit, which is hidden in an innocuous line

C#

for (int x = 0; x < myVar.Array.Width; x++)
   for (int y = 0; y < myVarArray.Height; y++)
      Console.WriteLine(myVar.Array[x,y]);

Looks like perfectly good code, but each access to the Array creates a new copy of the original.

Instead of an Array, use a List or similar collection.

Posted 10-Jul-20 5:22am

OriginalGriff

Comments

[no name] 10-Jul-20 11:30am

Can you give me a hint, why List instead of array should help? In my opinion also returning a List does not prevent from modify it. Where I'm wrong?
Thank you in advance.

OriginalGriff 10-Jul-20 11:40am

I absolutely agree - returning a List is just as bad, but ... that's MS for you.
Returning any collection is something to think about carefully, and probably to provide a method for instead of a property because it "hides" the copy operation a bit less.
You only get the error if the property is externally visible, so ...

Member 12712527 10-Jul-20 11:52am

Sir you're saying Lists are also bad. Is it viable to use static array or what will be the right solution....?

CHill60 10-Jul-20 11:57am

Provide a method rather than using a property

[no name] 10-Jul-20 12:02pm

I would say derive from Array or List and define an read-only interface (to return) is the 'correct' solution, but most probably overkill.

And also this does finally not prevent from casting the return value and modify it.

OriginalGriff 10-Jul-20 11:59am

Basically, don't use properties to return collections - use methods instead so it's more obvious that it might be a copy or "generated on the fly" collection.
Or make the containing class non-public: as long as it's contained in the assembly, VS shouldn't complain.