Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Just a few questions regarding best practices in c#:
Any reason why I'd prefer to do:
var list = new List<string>();
object[] array = list.ToArray<object>();
comboBox.AddRange(array);
instead of:
var list = new List<string>();
comboBox.AddRange(list.ToArray<object>());
Also any reason why I'd prefer to do:
class myClass
{
private string _hello;
public string Hello
{
get {return _hello;}
set {_hello = value;}
}
}
instead of:
class myClass
{
public string Hello;
}
Your first example just creates an intermediate variable to hold the converted array - if you don't need the array later on then logically they're equivalent.
Your second question is a more significant difference. Properties have many advantages over fields, including potential logic in the get/set accessors, binding to UI controls (most controls can bind to properties but not fields.
In general any public data members should be implemented as properties instead of fields. Non-public data members can be implemented as either.
There are lots of answers on SO that answer your second question.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I am starting to learn c# and I came across this error
Cannot convert implicitly convert Animal into
System.Collections.ArrayList
This is the code
private Animal adoptedPets;
public Animal AdoptedPets
{
get { return adoptedPets;}
set {adoptedPets = value;}
}
I am trying to set a list of Animals to this property of my object. I tried to cast my list like that (ArrayList) adoptedPets, but it didn't work and gave me the above error.
If you want adoptedPets to be a List<Animal> and not just a single Animal, you should declare it as such. Best would be to declare it a s
private IList<Animal> adoptedPets;
public IList<Animal> AdoptedPets
{
get { return adoptedPets;}
set {adoptedPets = value;}
}
Note the IListinstead of List. You could also use IEnumerable. It is a good pracice so that any kind of list can be assigned.
Now, I am assuming that you want your adoptedPets to store a list of Animals . But you are not precise at all in your question.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I've been having to use c# lately, which I don't have much experience in. a conundrum I keep finding myself in is, when building a class, having state be dependent on the state initialized before it
class foo{
public bar_ {get;}
public dum_ {get;}
public foo (){
bar_ = BuildBar();
dum_ = BuildDum(bar_);
}
}
its a bit redundant for BuildDum to carry a parameter if it's just going to use something already accessable from a member. on the other hand I like explicitly pointing out dependencies a function relies on
I guess I am asking: what is the best way to handle the situation?
Both ways are fine. The current version of BuildDum could be made static, in which case it's perfectly fine for the method to not access any member variables, because it cannot do it anyway:
private static Dum BuildDum(Bar b) {
...
}
If you make BuildDum that accesses bar_ directly, you should also make it access _dum, i.e. it should be a non-static void:
private void BuildDum() {
...
_dum = ...
}
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I want to create private list, while making it public as readonly\unwriteable, unable to add\remove\insert cells\nodes to the list.
My current solution is:
public IEnumerable<DataToken> DataTokens {
get {
return from v in _datatokens select v;
}
}
private List<DataToken> _datatokens;
I know the property's name is fine, but what about the variable's name? I can't name it dataTokens because it's parameter's name's format. Currently I call it _datatokens that is really bad name.
Is there a better alternative? I couldn't find anything about it at msdn.
Since identifiers are case-sensitive in C#, there is nothing against datatokens as a variable name.
There is a guideline available on MSDN that would suggests it to be dataTokens (camel-cased).
By the way, you should use ReadOnlyCollection<T> as return type to make it read-only to the outside world, so I would suggest to split this one up in two properties with different access modifiers.
C# also supports auto-properties, so you can save yourself the trouble of solving this conundrum and simply declare your property thus;
public IEnumerable<DataToken> DataTokens { get; private set; }
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a class and use private vars in that class, is there any need then for setter or getter?
I think they are just needed if I want to access the vars from another class right?
You're sort of right.
If you need to expose any of your private fields to other classes, you'll want to generate a property with the appropriate access modifier (public, protected, internal, or protected internal).
If you don't need to expose your private fields, reading from/assigning to a field directly is usually fine.
But even so, having private properties encapsulating private fields might be useful in some cases, such as:
when you need to validate a value before assigning it to the field;
lazy loading a value before reading from it, etc.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a object which is used in another context and I want to validate if a private member is null or empty (which is exposed by its property). It would be better to declare inside the class of the object to encapsulate the behavior instead of doing the validation at every moment where is used, but the question is if better to do it as a property or method?
public bool HasValue()
{
return String.IsNullOrEmpty(this.privateMember) == false;
}
or
public bool HasValue
{
get
{
return String.IsNullOrEmpty(this.privateMember) == false;
}
}
Example of usage:
if(myObject.HasValue()){
}
or
if(myObject.HasValue){
}
What is better? Any impact or it just visual?
Well that certainly feels more like a property to me than a method - and it's certainly in-keeping with things like Nullable<T>.HasValue.
Other differences to consider:
You can generally bind against properties but not methods; not sure you'd want to bind against this anyway
You can't use properties for method group conversions (unfortunately) to create delegates
Properties are automatically evaluated when debugging; methods aren't
There shouldn't be any performance impact.
As an aside, rather than comparing against false, I'd write the implementation as:
return !string.IsNullOrEmpty(privateMember);
It doesn't have many impact for the compiler its just visual but i prefer the second one i'm always doing hate the () :)
System.Nullable<T> uses the property HasValue, so I would use the same approach for consistency with the .NET Framework.