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 want to know how many parameters can be passed to function, I mean what is good programming practice, regarding passing the parameters to function?
Code Complete suggests a maximum of 7. This is because of The Magical Number Seven, Plus or Minus Two:
...the number of objects an average human can hold in working memory is 7 ± 2; this is frequently referred to as Miller's Law.
Here's an excerpt from Code Complete 2nd Edition:
Limit the number of a routine’s parameters to about seven
Seven is a magic number for people’s comprehension. Psychological research has found that people generally cannot keep track of more than about seven chunks of information at once (Miller 1956). This discovery has been applied to an enormous number of disciplines, and it seems safe to conjecture that most people can’t keep track of more than about seven routine parameters at once.
The fewer the better, but only if it still makes sense. I've never heard of a standard number of params to be passed, but I have heard of ways to keep them down better.
For example, don't do this:
public void DoSomething(string name, int age, int weight, ...) { }
but rather:
public void DoSomething(Person person) { }
but hopefully that goes without saying. But also, I would recommend not creating a weird class just to trim down the parameter count.
IMHO 5 at MAX.
6 is too much for me and 7 overwhelming!
According to Clean Code - maximum 3
If you have many things you would like to pass to a function you may want to look at some other means of transferring that data as opposed to simple parameter passing. For example in certain cases it may be better to generate an XML file and then pass values related to getting data around that XML file. If you are running a web app it may be simply passing data through sessions or post rather than get or function calls that will simplify your life.
Also you may want to store some of that information as member variables.
I would recommend no more than 4. You don't want your lines to get much longer than 30 characters long unless you are generating some massive string, but even then it becomes really unreadable and gross (although necessary especially for javascript).
It's good programming practice to write programs so that they are easy to read. Personally I try not to write functions which have more parameters than can be displayed on one line on the screen. Usually that is no more than five or six parameters at most.
some ARM compilers pass three or less parameters using registers and any more than three are stacked. The stacked type call is slower than the call using registers so in this case you should use three or less parameters, for speed.
Depending on the architecture, more than 1-3 will cause passing on the stack. This is slower than passing via registers. From a performance standpoint, it is best to pass either a pointer to a wrapper class or a pointer to a struct. This ensures that only one value is passed in and saves some writes/reads to memory.
If you don't know how many parameters you are going to pass to a function use param for sending variable arguments to a method.
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 5 years ago.
Improve this question
I guess this question is for a large part a matter of what you prefer aswell as being very situational, but I just came across a path to a gameobject today with a pretty long reference, and I thought if a temp reference wouldn't be better for this situation.
The code:
if (enlargeableButtons[i][j].gameObject.activeSelf && enlargeableButtons[i][j].IsHighlighted())
{
enlargeableButtons[i][j].gameObject.SetIsHighlighted(true, HoverEffect.EnlargeImage);
}
In a case where the path is this long with multiple array indexes to check, it would definitely be faster, but because of the extra object also be more expensive to do it like this:
GameObject temp = enlargeableButtons[i][j].gameObject;
if (temp.activeSelf && temp.IsHighlighted())
{
temp.SetIsHighlighted(true, HoverEffect.EnlargeImage);
}
But how much and would it be worth it?
I seriously doubt you will see any performance gain using a direct reference instead of going through the jagged array.
Maybe if this code is running in a very tight loop with lots and lots of iterations, you might get a few milliseconds of difference.
However, from the readability point of view, the second option is much more readable - so I would definitely go with it.
As a rule - You should design your code for clarity, not for performance.
Write code that conveys the algorithm it is implementing in the clearest way possible.
Set performance goals and measure your code's performance against them.
If your code doesn't measure to your performance goals, Find the bottle necks and treat them.
Don't go wasting your time on nano-optimizations when you design the code.
and a personal story to illustrate what I mean:
I once wrote a project where I had a lot of obj.child.grandchild calls. after starting to write the project I've realized it's going to be so many calls I just created a property on the class I was working on referring to that grandchild and my code suddenly became much nicer.
Declaring GameObject temp just creates a reference to enlargeableButtons[i][j].gameObject. It is extra overhead, but not much. You won't notice a difference unless you're repeating that thousands of times or more.
As a personal rule, if I just need to reference it once, I don't bother with declaring a variable for it. But if I need to use something like enlargeableButtons[i][j].gameObject multiple times, then I declare a variable.
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'm working on a project that was made by another developer, and I've been assigned the job to add extra functionality, although this question isn't about one application, it's about a language.
In C#, I find myself running across this probably around 50 times a day, I need to grab a value from a method and store it to a variable, or I need to store a variable, or even if I just need to hard code a variable to something.
Do I go with my head or my heart? My head says store it in a variable incase I need to use it more than once in the future, but then my heart says lets be lazy and just add it to the if check, instead of calling the variable, let me give you an example...
Example 1:
var name = SomeClass.GetName();
if (name.Contains("something"))
{
// do something
}
Example 2:
if (SomeClass.GetName().Contains("something"))
{
// do something
}
I guess what I am asking is, does it have any sort of advantage? Or does it not really matter?
Am I using memory by storing these? especially if I'm storing hundreds across a solution in all different types of methods?
Is it worth just using it inside the if directly for an advantage, or should I just have a variable just in case? Can anyone explain the difference? If there is any that is.
I'm talking about if I only ever use the variable once, so don't worry about the "having to change in multiple locations" issue, although if anyone does want to go into that aswell, I would appreciate it.
I think there will not be any notable advantages in performance wise as well as in memory-wise. But when we look into the following scenarios storing return values have some advantages.
The calling method(SomeClass.GetName() in this case) may return null
Consider that the SomeClass.GetName() may return null subject to some conditions, then null.Contains() will definitely throw NullReferenceException [This will be same in both examples that you listed] in such case you can do something like the following:
var name = SomeClass.GetName();
if (name!= null && name.Contains("something"))
{
// do something
}
Need to use the return value more than one time:
Here you are using the return value only for checking the .Contains("something"), consider that you wanted to use the return value later in the calling method, then it's always better to store the value in a local variable instead for calling the method repeatedly. If it's only for checking contains then change the return type to boolean and finish the job within the method
Ask yourself this question about this line of code:
var name = SomeClass.GetName();
How expensive is GetName() method? Is it going over the internet and downloading a file from somewhere and it takes seconds to minutes to download the file? Or is it doing some crazy computation that takes a few seconds to minutes. Or is it getting data from the database? These answers will help you decide if you should store it in a variable and then reuse the variable.
The next question even if the above answers were "Na! It is pretty quick and does nothing fancy" is to ask yourself this: "How many places in the current class are you making this call? 1? 10? 100? If your boss comes one day and says, "You know that method GetName(), well we are not going to use it anymore. We will use another method named GetName2()". How long will it take? Well imagine if you need to make the changes in 100 different places.
So my point is simple: It all depends.
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 6 years ago.
Improve this question
I had an argument with my teammate about the following.
We need to parse a symbol in a string to int(it is always a digit), this particular functionality is used in a number of places. So this can be done this way:
var a = int.Parse(str[i].ToString());
The argument was: do we need to create a function for this.
int ToInt(char c) {
return int.Parse(c.ToString());
}
that can be used:
var a = ToInt(str[i]);
My opinion is that creating such a function is bad: it gives no benefits except for typing couple characters less (no, as we have autocomplete), but such practice increase a codebase and makes code more complecated to read by introducing additional functions. My teammate's reason is that this is more convinient to call just one such function and there is nothing bad in such a practice.
Actually question relates to a general: when it is ok(if at all) to wrapp combination of 2-3-4 functions with a new function?
So I would like to hear your opinions on that.
I argee that this is mostly defined based on personal preferences. But also I would like to hear some objective factors to define a convention for such situations in our project.
There are many reasons to create a new sub-routine/method/function. Here is a list of just a few.
When the subroutine is called more than once.
If it makes your code easier to read/understand.
Personal preference.
Actually, the design can be done in many ways of course, and depends on the actual design of the whole software, readability, easy of refactoring, and encapsulation. These things are to be considered on each occasion by its own.
But on this specific case, I think its better to keep it without a function and use it as the first example for many reasons:
Its actually one line of code.
The overhead of calling a function in performance will be far more the benefit you get from making it.
The compiler itself probably will unwrap it again into the one line call if you make it a function, though its not always the case.
The benefit you get from doing so, will be mainly if you want to add error checking, TryParse, etc... in the function.
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
Which is best?
private long sumVals()
{
return (dbReturn("NUns") / dbReturn("TSpd")) * 60;
}
private long dbReturn(string dbField)
{
// ... access db, get value
return retVal;
}
or
private long sumVals()
{
long numUnits = dbReturn("NUns");
long targetSpeed = dbReturn("TSpd");
return (numUnits / targetSpeed) * 60;
}
private long dbReturn(string dbField)
{
// ... access db, get value
return retVal;
}
Is it better to try and put it all onto one line, so there is less code overall, or to spread it out like in the second one?
Is one or the other quicker? Is there a benefit, eg, while compiling?
Your case is simple, so the first one is OK. But in general, I would go for the second one.
It is important that you (and others) can read the code, but you don't need to save memory (fewer lines of code as well as fewer variables).
Your code will be easier to understand and debug if you choose to write it the second way. You also don't have to have a lot of comments if your variable names explain the code well enough, which makes your code easier to read in general. (I am not telling you to stop commenting, but to write code which does not need trivial comments!)
See this question for more answers.
My rule of thumb is to include enough content to fully describe what the intent of the code is, and no more. In my opinion, assigning values to variables only to use those variables immediately is actually less readable. It communicates the flow of the program well enough, but doesn't communicate the actual intent.
If you renamed the function from dbReturn to GetDatabaseValue then I don't think I can come up with a more expressive way to write this function than:
return (GetDatabaseValue("NUns") / GetDatabaseValue("TSpd")) * 60);
This communicates the intent perfectly (notwithstanding the fact that I don't know what "NUns" and "TSpd" mean). Fewer symbols means fewer things to understand when reading the code.
Full disclosure: Including extra symbols does improve debuggability. I write this way when I am first building a function so that I can track down where things go wrong. But, when I am satisfied with the implementation, I compress it down as much as possible for my and my co-workers' sanity.
As far as I can tell, there would be no run-time performance gain achieved by either approach. Compilers are awesome - they do this inlining without your knowledge. The only difference is in the code's readability.
To me, longer is always better. Modern compilers will shrink most code to be very fast. However, being able to maintain code through lots of comments and easy-to-read code is hugely important.... especially if you are one of those guys who have to maintain someone else's code!
So, my vote is the longer version (with a comment explaining what you are doing too!)
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 6 years ago.
Improve this question
I'm writing a library and instead of returning a byte array from an EventArgs derivation, it says I should return something like IList or ReadOnlyCollection instead.
Normally I'd be all for this but most of the existing .NET Framework uses byte arrays as opposed to generic list interfaces.
So if I were to use IList then when accessing the eventargs, if a client wanted to call File.WriteAllBytes he or she would have to do using System.Linq; and call the ToArray extension method to get the IList in the form of an array of bytes. Of course there are other ways to do this but this is the most elegant and typical.
Clients of this library are always going to want things to be in terms of an array of bytes so that they interface nicely with the rest of the framework.
Also, optimization may come in to play here. There is potential for large amounts of bytes to be manipulated so having to recopy the entire list just to get it in the form of a byte array each time would likely slow things down.
Lastly, it's just plain unpleasant. If clients are always going to want a byte array, then why not just give it to them? Do framework design guidelines not apply in this situation? What would you do?
There is potential for large amounts of bytes to be manipulated so having to recopy the entire list just to get it in the form of a byte array each time would likely slow things down.
But that is precisely why it should not be a byte array. Suppose you do this:
byte[] x1 = GetByteArray();
x1[0] = 0;
byte[] x2 = GetByteArray();
Every time you call GetByteArray you have to create a new byte array. Why? Because someone might have changed the one you handed out last time to have different contents! By handing out a byte array you guarantee that you are going to have to reconstruct that byte array from scratch every single time.
By contrast, if you hand out a read only collection of bytes then you can hand out the same collection over and over again. You know it is not going to change.
Clients of this library are always going to want things to be in terms
of an array of bytes so that they interface nicely with the rest of
the framework.
There you have your answer - FxCop output is in most cases just helpful suggestions - not commands - if this particular one doesn't apply to you you can even turn it off.
The guidelines and recommendations offered by FxCop are not always applicable in every situation. You don't need to follow them, and in some situations you shouldn't.