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
According to ReferenceSource, the Version class is sealed, ICloneable, IComparable, IComparable<Version>, IEquatable<Version>. It also only stores int values. Is there a particular reason why the .NET programmers chose to make this a class instead of a struct? Why would someone need a null version?
Here's the field declaration block from ReferenceSource:
// AssemblyName depends on the order staying the same
private int _Major;
private int _Minor;
private int _Build = -1;
private int _Revision = -1;
They even make a comment, saying they need to keep the fields aligned. Maybe it's just me, but this is really a struct thing?
Why would someone need a null version?
To specify that no version is specified, for instance in AssemblyName as referred to in the comment in your question. An AssemblyName may omit the version when passed to Assembly.Load, for instance, in which case its Version property will be null. Remember that these types were created for .NET 1.0, which didn't have generics, so Nullable<Version> didn't exist yet as an alternative.
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 3 years ago.
Improve this question
I have a methode searching for a winform control by name. My first approche was to do it like that
private Control SearchControlByName(Control parent, string name){recursive search...}
Calling the methode looks like
Label temp = (Label)SearchControlByName(panel1, "label4");
Then a thought to myself it would be better do do it with an generic methode like this
private T SearchControlByName<T>(Control parent, string name) where T : Control {recursive search}
calling like
Label temp = SearchControlByName<Label>(panel1, "label4");
And now I'm not sure which is the better approach. What are the advantages / drawbacks of the generic method vs casting after calling the method?
In the generic methode I also have to cast the result like this
return (T)result
I don't think there are any disadvantages.
Since there are at least two advantages (see below), I would use the generic version.
It's prettier (no need for that cast).
You could use OfType<T> on Control.Controls inside the implementation (your recursive search) so you don't have to worry about returning a Label when the person wants a PictureBox. However keep in mind that you can only do that at the bottom level, otherwise you won't go through all the elements of course.
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 5 years ago.
Improve this question
I've got this idea from Java - i was told that you should declare a collection like this
List<Object> myList = new ArrayList<Object>();
where ArrayList is a class implementing List interface. The point of this is to enhance maintainability by generalizing code - as, should you change teh implementation to, e.g LinkedList<Object>, you could to it 100% painlessly.
So, projecting this on C#, is it considered a good practice to do the same thing in C# :
IList<Object> list = new List<Object>()
?
EDIT : i just found that LinkedList in C# does not even implement the IList interface, so i guess it settles the question for lists at least
Yes, generally this is a good practice to use interfaces wherever you can.
There are two important exceptions for containers, though:
When you must use a hash-based container for objects that are not comparable, use HashSet<T> or Dictionary<TK,TV>,
When you declare a local variable, using var for implicit typing is often preferred for convenience,
Note that if you plan to use a sorted container you have IOrderedSet<T> and IOrderedDictionary<TK,TV>.
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 5 years ago.
Improve this question
I have seen that the majority of well-known developers (such as those in Lynda, Pluralsight, etc. or even writers) nowadays prefer the following approach over the latter one:
private IField _Field;
publc MyClass (IField Field){
_Field = Field;
}
Over this approach:
private IField Field;
public MyClass(IField Field){
this.Field = Field;
}
I know that there must be a reason behind this, but I can't figure out why.
Since this trend has began by the time C# 6 was released, I guess the reason might be due to something relating to Roslyn compiler but could not find anything over Google.
I'd appreciate if anyone could elaborate what advantages the first approach may possibly have over the second one.
It is just one naming convention - a lot of people coming from C and C++ backgrounds are used to this convention, as it makes it very clear that a field is a field, which is not as easily visible in those languages (given the IDEs that existed when they were invented).
With C# and particularly Visual Studio giving one a lot of help with idenifying members and their scope, this is less needed.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have to make extensions for all types arrays of numbers : ints, longs, floats, doubles, etc. that can do some things.
Of course, I could do it for every type of integers, but that would look ugly.
double GetSomeValue (int[] array)
{
// some code
}
double GetSomeValue (double[] array)
{
// some code
}
etc, etc...
Is there any nice way to make in a short manner ?
Short answer is no. Depending on what you are actually trying to do you can use generic method declaration but it will accept broader set of types, cause there is no way to restrict generic method to accept only numeric types in C#.
Also an option would be using T4 Templates like here
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'm creating this constant on a web service :
private const int SiteId = 4;
I understand that it should be Pascal Notation but resharper suggest me to use the D in capital, so the word ID is all uppercase like this :
private const int SiteID = 4;
What's the proper naming convention for this particular case ?
NOTE: Found lot of answers already on SO but none have the word ID on their examples.
As Cam said, it's a matter of preference.
I prefer "Id" simply because it's an abbreviation not an acronym. You wouldn't write Site IDentification, so why write SiteID?
Perhaps this convention stems from the fact that it is usually spoken "site eye dee" as opposed to "site idd".
http://msdn.microsoft.com/en-us/library/vstudio/ms229043(v=vs.100).aspx
The two abbreviations that can be used in identifiers are ID and OK. In Pascal-cased
identifiers they should appear as Id, and Ok.
It's really personal preference. Personally, I like my constants to be all caps.