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.
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 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 2 years ago.
Improve this question
I am trying to figure out the best way to change an existing class.
So the class is called ExcelReport and it has one method Create(data,headings).
This is live and used in many places.
Now recently I want to change the method so I can format columns in excel.
Create(data,headings,columnformats)
So as not to upset my existing programs the best I can come up with is to add another method
Create2(data,headings,columnformats) to the class.
o.k I got a lot of suggestions saying I should modify the existing class with a overloaded method, which I did.
But does this not break the Open/Close Principle as my existing class was in production. Should I have created a new class ExcelReport2(and Interface) with the new improved method and passed this into my new program using dependency injection ?
Regards,
Niall
As the comments suggest the best approach is likely to use an overload method. In most cases I would approach this with the idea of implementing the overload method as a pass-through if possible.
Create(data, headings, columnformats)
would transform the data using the column formats and call:
Create(data,headings)
at the end of the method. This means in all cases of the Create method call the version with 2 parameters while the cases that need 3 are handled as a pass-through. This keeps to a rule of least disturbance and avoids confusion if the code needs to be maintained in the future since you are not duplicating the logic in:
Create(data,headings)
Edit: One important consideration with this approach is that if columnformats does not modify the data or headings you may not be able to practically use this as outlined. In that case you would use Create(data, headings, columnformats) as the base method with Create(data,headings) acting as a pass-through to that function. In this case Create(data,headings) would set a default value that is then passed to Create(data, headings, columnformats)
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
calling method in foreach loop like
foreach (object ofr in DataHelper.GetOffers(id, object))
is better
or take this DataHelper.GetOffers(id, object) out and assign that to variable like foreach (object ofr in variableObject) which is the better way and which will perform better and why?
Thanks
Neither is better and both will perform the same.
It's a matter of personal style preference.
IL code will be optimized in both ways in the release. So, either way, it will be the same in terms of performance.
In both cases you are only calling DataHelper.GetOffers(id, object) once. Thus there are no performance implications either way.
When people talk about moving methods calls out from loops they mean the loop's inner scope or the loop's body. Because if it's a call that can be made only once, you are wasting time by doing it in every loop's repetition.
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
It may be a silly question, but since I can't give it an answer by my own, I will ask it here.
Let we have a module that we want to use in an http handler (the web app is written in C# using ASP.NET) and let that this module implements the IDisposable interface. Then a common approach is to
use the module as below:
using(var module = new ModuleName(param1, param2, param3))
{
}
Is it better to place any code to variables that we are going to use only inside the body of this using statement or before this. In terms of code:
Is it better (and why) the first approach or the second approach:
first approach
using(var module = new ModuleName(param1, param2, param3))
{
int a = Request.GetParam<int>("aNumber");
string b = Request.GetParam<string>("bString");
// and other parameters contained to the http request
}
second approach
int a = Request.GetParam<int>("aNumber");
string b = Request.GetParam<string>("bString");
// and other parameters contained to the http request
using(var module = new ModuleName(param1, param2, param3))
{
}
If there isn't any technical reason -and it is an opinion based decision- that we should prefer the first approach to second approach or vice versa, please let me know, in order to delete my post.
It depends on if you need those variables outside of the scope of the using-statement. If so, you need to declare them outside anyway. If not, declare them in the using.
Why? It's all about readability, fail-safety and refactoring.
This is true not only for the using but scopes and variable declaration in general. Read:
https://codereview.stackexchange.com/questions/6283/variable-declaration-closer-to-usage-vs-declaring-at-the-top-of-method
https://softwareengineering.stackexchange.com/questions/56585/where-do-you-declare-variables-the-top-of-a-method-or-when-you-need-them
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 ... :)