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
(questionn is misspelled on purpose: stackoverflow does not allow the word "question" in the title)
Consider a property SomethingHasChanged
This can be read as a statement, SomethingHasChanged!, or a question, SomethingHasChanged?
What are the conventions (C#) for naming booleans? As statements or as questions?
Background
All code of a client I work for, is written in Dutch. In Dutch there is a slight difference between these two forms that in English does not exist. Therefore we need to make a decision between the two forms. Example: ErIsIetsGewijzigd! vs IsErIetsGewijzigd?
Many boolean properties start with Is or Has , e.g.:
this.IsRed = this (object) is red
this.HasChildren = this (object) has children
Your name doesn't really fit this convention well:
this.SomethingHasChanged = this (object) has something that has changed.
To match this convention, I'd rename your property IsDirty or similar.
A Boolean variable or property is an outcome of an expression, therefore, it is not a question, but a statement.
If, instead, you are asking a question, which requires an operation to answer it, than it should be a method and may be named as such.
It depends on whether you want to communicate you read state or determine it on request. A property bool HasChanged {get; set; } can be called twice and it should result in the same stored value. However a method bool HasChanged() communicates it is going to determine it for you on demand.
Finally, as I am Dutch as well, ErIsIetsGewijzigd sounds like a command, therefore as I read it, it should set the property, i.e. ErIsIetsGewijzigd(true);.
Related
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 1 year ago.
Improve this question
I am trying to understand thought process behind this design decision. Also return type of Dictionary.Add is void. It would be nice to have same behavior for both data structures. Or is there any use case which makes current implementation a better choice?
The HashSet class is based on the model of mathematical sets and provides high-performance set operations similar to accessing the keys of the Dictionary<TKey,TValue> or Hashtable collections. In simple terms, the HashSet class can be thought of as a Dictionary<TKey,TValue> collection without values.
I am trying to understand thought process behind this design decision
Only the person or people who actually made the decision can provide that. They are unlikely to see your question here, though of course that possibility can't be ruled out.
is there any use case which makes current implementation a better choice?
There are lots of use cases. But the main thing to keep in mind is that adding the same object to a set (like HashSet<T>) that is already in the set is non-destructive, while adding the same key to a dictionary (like Dictionary<TKey, TValue>) is destructive, i.e. it overwrites the existing value.
Having the Add() method return a bool like HashSet<T> does wouldn't be helpful; by the time you see the false value that's been returned, the old value for the key will have already been replaced.
That said, do note that the indexer for dictionaries will overwrite the existing value silently. So in fact, dictionaries have exactly the same functionality that HashSet<T>, plus the capability to prevent you from accidentally overwriting a value that's already been stored.
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 3 years ago.
Improve this question
Does anyone know how to convert the C# getter and setter to a java-like getter and setter pattern using the Rider IDE?
Convert this:
public Transform List
{
get { return list; }
set { list = value; }
}
to this
public Transform GetList() { return this.list; }
public SomeClass SetList(Transform list) { this.list = list; return SomeClass; }
This would be usedful for chaining setters in a fluent builder pattern.
A distinct non answer: stop wasting "double" your time!
C# isn't Java. Fighting a tool to fight the native idiomatic constructs of your target language, that is likely double pointless.
Source code is written to be read by humans. And good source code never surprises its readers. An experienced c# programmer will look at your Java like getters and setters and can only wonder: "why is he polluting these classes with those strange methods, instead of using c# property support".
Beyond that, you might want to read https://en.m.wikipedia.org/wiki/Uniform_access_principle to understand why the c# properties are actually a better approach than Java fields with getter/setter pairs!
Or as they said 2 thousand years ago: when you come to Rome, do like the Romans do! If you don't want to do like the Romans do, stay away from Rome, or c# in your specific case.
OP is probably coming from the java world. In the Menu(Intellij) Java IDE ->Code->Generate
In the generate menu, "Getter and Setter" is the 4th Option.
In the C# world(Rider), properties are used to expose selected fields.
Jetbrains Recommends generating Properties rather than the Java getter-setter way.
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
There are times I instantiate a new object within a method call for sake of streamlining code instead of assigning the new object to a variable. What drawbacks exist in doing one or the other?
T myobj = new T();
elements.Add(myobj);
--vs--
elements.Add(new T());
Need a reference later
As adaam mentioned in the comments, if you need to keep a reference to an object because you'll be using it, then it's better to do it this way.
T myobj = new T();
elements.Add(myobj);
T.DoStuff(); //this might need to happen further down in the code, so keeping the reference is handy. Otherwise we'd have to dig it out of the elements. And you might be thinking "well, I don't need to reference it later in the code." But what if you're refactoring the code and it requires some modification? Now you'll need to change it, rather than having done it with a separate declaration in the first place.
Debugging
A common situation is when you're stepping through code with the debugger. It's difficult to see properties of an object that was created in this manner.
elements.Add(new T());
When given its own reference, you can easily use your IDE's debugging tools to check the values if the code is written like this:
T myobj = new T();
elements.Add(myobj);
Readability
Another reason to choose one over the other would be readability. That one is opinion based, but you should ask the team you're working with which is more readable in order to determine which practice to follow. Asking everyone on Stack Overflow which reads better is off topic.
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
Short and sweet (hopefully), is there a specific reason not to use the this keyword when writing getters and setters in C#? I know the typical format, and the one I've always used, is:
public void SetDay(int _day) { day = _day; }
public int GetDay()
{
return day;
}
Recently though, I've been learning Java, and in several of the books I've been using I've seen it written instead like this:
public void SetDay(int _day) { this.day = _day; }
public int GetDay()
{
return this.day;
}
So basically, is there a reason to avoid doing it the same way in C#? Will it cause any problems or errors, or is it a valid approach and really just a matter of personal preference. I'm wondering because, while I know the this in C# is understood, explicitly using the this keyword seems like it would aid in eliminating a bit extra ambiguity, which personally is always a good thing.
Thank you!
There's not much to it really.
You can do it, and you can avoid it. I think it's quite obvious when you're in the getter/setter that you're talking about the object you're in, so I've never used it there.
Also, it seems like Resharper will suggest it's redundant, and gray it out.
If you find it to be of use for you (readability wise), by all means, use it. Otherwise, it'll save you five keystrokes (about a second?) every time you implement a getter by hand ... :)
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
Naming conventions imply that (typically) properties are nouns, methods are verbs. Now, I know these are guides, not rules, but it's something best to follow a guide when you can.
This means, the following
Person.Name = "Dave";
should only set the Name property. I would not expect the property to look like
public string Name
{
set
{
UpdateDatabase(value);
}
}
My question is pretty much exactly the example above but in relation to DependencyProperties.
My application has a UserControl, it looks like
<uc:MyControl MyControlMyValue="{Binding RelativeSource={RelativeSource AncestorType=userControls:MyOtherControl}, Path=MyValue, Mode=OneWayToSource}" />
So, as you can see in the above, when the MyControlMyValue property is updated, it updates the MyValue property. The problem I have is when this property is updated I need it to perform more logic than simple binding!
At the moment, I'm voting to ignore the guide and implement something like
private double _myValue;
public double MyValue
{
get { return __myValue; }
set
{
if (value == __myValue)
return;
__myValue= value;
LookAtMeHiddenAway();
OnPropertyChanged("MyValue");
}
}
Is there a better approach as it does feel very wrong to me?
Well, it depends.
If we are talking about general programming guideline, I would say no. Do not call methods inside properties, as I and others when we use properties (write/read) we expect of storing and retrieving data. So if you are going to change something, change it by calling a method, that manifests by declaration its behavior.
In case, instead, of WPF that is actually an expected behavior. So in case of WPF properties are suitable for changing data inside and are expected to behave in that way.
Bottom line: there are no strong restrictions on subject, but suggested guideline that is based on expected behavior of the code in the given environment.
I would create an event called OnMyValueChanged and anything that needs to update when that property changed would register a handler to that event. Or handle the PropertyChanged event. It's the same thing really, but it avoids putting logic in the setter that is not directly applicable to the property (eg constraining the value).