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.
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 7 years ago.
Improve this question
I have some methods in a class which get called by only one method in the same class. Where is the best practice to put such methods? Private at the end of the class?
Comming from gcc's C implementation I would define those helper methods in the method they are needed for, but that doesn't seem to work in C#.
I often use Private methods at the end of the class, as you mention. But if those helper methods are closely related to the calling method, you could place them right after the calling method and surround it all in a #region to visually group them, as well as allow for expanding/collapsing as a unit in Visual Studio.
#region Range Checking
public void CheckRange(int lowerBound, int upperBound)
{
CheckRangeValue(lowerBound);
CheckRangeValue(upperBound);
}
private void CheckRangeValue(int value)
{
//...
}
#endregion
In Bob Martin's excellent book Clean Code, there is a chapter on vertical formatting, with a section titled "The Newspaper Metaphor". I'll post an excerpt (emphasis mine):
Think of a well-written newspaper article. You read it vertically. At the top you expect a headline that will tell you what the story is about and allows you to decide whether it is something you want to read. The first paragraph gives you a synopsis of the whole story, hiding all the details while giving you the broad-brush concepts. As you continue downward, the details increase until you have all the dates, names, quotes, claims, and other
minutia.
We would like a source file to be like a newspaper article. The name should be simple but explanatory. The name, by itself, should be sufficient to tell us whether we are in the right module or not. The topmost parts of the source file should provide the high-level concepts and algorithms.
Detail should increase as we move downward, until at the end we find the lowest level functions and details in the source file.
And a few pages ahead:
If one function calls another, they should be vertically close,
and the caller should be above the callee, if at all possible. This gives the program a natural flow. If the convention is followed reliably, readers will be able to trust that function definitions will follow shortly after their use.
(...) [T]he topmost function calls those below it and (...) they in turn
call those below them. This makes it easy to find the called functions and greatly enhances the readability of the whole module.
Besides this specific topic, the book contains a ton of other very, very useful well-funded information about these sometimes neglected aspects of code construction.
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 8 years ago.
Improve this question
This is basically a a design question:
I am rewriting an application in C# which is basically written in C++. C++ has this nice concept of Header files which will gold a lot of declared constant values for the consuming file.
However, we do not have Header files in C#. I may have two options
Create a class which will hold a lot of constant values for me(No so standard)
Store values in XML (Standard-But involves a lot of parsing hassle)
Which is a better solution? Is there any other solution that I may not know of?
Personally i'd use a static class and place all the values in there.
public static class Constants
{
public const int Ten = 10;
public const int Twenty = 20;
....
}
EDIT
As #JonSkeet suggested, it's better if you store these values in classes they pertain to, however, that might not always be possible.
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).
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 4 years ago.
Improve this question
I have a class with two related functions (methods):
public class class1
{
public void SubscribeToListOfEvents()
{
// ....
}
public void UnSubscribeFromListOfEvents()
{
// ....
}
}
What's the best practice to use related functions in one class ?
Do you know of any implementations of related functions as one function ? Are they good ? In what situations are they good ? If so, can hyou give me an example?
Any available options of code above will be appreciated.
If the functions belong to the class, logically, then they are fine that way.
A class should be cohesive and methods that do an operation normally should have the mirror operation defined as well (Subscribe/Unsubscribe, Add/Remove etc...).
You have named them well, as they are very descriptive of what they do - how would you name a merged one? It is better to leave them separate, as this way they are self documenting and will not confuse users of the class.
With the example you provided, they are related - but only because they may work with the same set of data or objects.
Personally i would NEVER merge these into a single function. While it may be more typing, it is easier both to read and to maintain to keep them separate. When either of those two functions are being called it is obvious what is going to happen - if you were to merge them then it becomes not so obvious. This is a simple example though - if you were to merge two functions that were more complicated then things could get very murky, and you could end up having unintended side effects from calling the merged function.
Remember KISS - Keep It Simple, Stupid :) For every function, try and follow SRP - Single Responsibility Principle. While Wikipedia talks about SRP at the class/object level, there is no reason to not also apply it at the function level where practicable.
dont merge them, make an interface that will force you implement both methods
interface ISubscriber
{
void Subscribe();
void Unsubscribe();
}