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.
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
In C# 8.0 we can now use using declarations in C# 8.0. Are they really such a good idea? Consider this using statement:
private int SomeMethod()
{
using (var t = new StreamWriter("somefile.txt"))
{
} // dispose of variable t
// 100 lines of code
}
As soon as the closing brace is reached, the variable t is disposed of. With using declarations, the scenario is different:
private int SomeMethod()
{
using var t = new StreamWriter("somefile.txt");
// 100 lines of code
} // dispose of variable t
The variable t is only disposed at the end of the method. Using statements seem more efficient to me, because you only keep the object "alive" for as long as you need it.
The answers can be as many as different scenarios.
In your case for example it could either be:
The function is big enough that it do would make sense to split. Remember that in modern programming with unit testing in mind, the units must be sufficiently small and the functions to do specific things.
The 100 lines will end in quite quickly. If that's the case, then it's ok to use the new more readable definition.
The same resources are needed a few lines below. Then why not use the same instance and then dispose?
In the rest of the lines, something else happens that takes time. Then it does not make sense to keep an item non-disposed (like a Stream) and the old way should be used.
The list could go on. There is no one solution fits all example but in most cases I think the first applies.
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 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
The Complex structure in System.Numerics allows assignment like this
Complex c = 3.72;
If I wanted to make my own Complex struct, how would I program this capability? I like it better than using constructors as in
Complex c = new Complex(3.72);
You need to declare an implicit conversion operator.
Thanks Code-Apprentice for the correct answer. I will just post exactly the code I added to my Complex struct
public static implicit operator Complex(double x)
{
return new Complex(x); // implicit conversion
}
This seems to work.
I will clarify why I am doing this. I wrote a large modeling code using Microsoft Complex everywhere. I tried to use the code in a Xamarin forms project but I could not get a reference to System.Numerics. To make progress I had to resurrect an old Complex struct I had made years ago, and get it to match the Microsoft capabilities.
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.
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'm a little bit confused why type instances are allowed to be created without their future use and the compiler doesn't emit even a warning about it.
public void M()
{
new int();
new object();
}
I've never created an instance without assigning it to a variable or calling it's members, and if I saw a line like ;new SomeType(); I would consider it as a mistype. I understand that technically .ctor can assign some static fields or do something else it's not supposed to do, but I don't consider it a sufficient argument for not emitting a warning.
Are there any patterns where ignoring an instance is appropriate? What am I missing?
Additional points not clear for me:
1. CodeAnalysis gives a warning "CA1806: Do not ignore method results" for object but not for int or any other value type.
2. The compiler doesn't emit IL for ignored structs even without optimization flag.
Instantiating an object can have side effects in C#.
The constructor could do almost anything, such as creating a database entry, writing a text file, or updating a static property somewhere before going out of scope.
Having said that, it is not good programming style to instantiate an object for the sole purpose of producing a side effect. That is what the CodeAnalysis warning is implying.
I understand that technically .ctor can assign some static fields or do something else it's not supposed to do, but I don't consider it a sufficient argument for not emitting a warning
As Eric Lippert said
My usual response to “why is feature X not implemented?” is that of course all features are unimplemented until someone designs, implements, tests, documents and ships the feature, and no one has yet spent the money to do so. And yes, though I have famously pointed out that even small features can have large costs, this one really is dead easy, obviously correct, easy to test, and easy to document. Cost is always a factor of course, but the costs for this one really are quite small.
http://blogs.msdn.com/b/ericlippert/archive/2009/05/18/foreach-vs-foreach.aspx