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!)
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 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 6 years ago.
Improve this question
In my project, there are a lot of code chunks that a reused under different conditions. These chunks are just a few lines of code. The calls of these chunks are spread all over the program and some of theme depend ob which mode the program is running.
I now want to provide this code in a easy to access way with a good performance.
I've two attempts in mind.
a) Create a static class with functions, each containing one chunk of code.
b) Creating several small classes (components) each with an execute method holding one chunk of code.
I'm not sure which is a clean way to handle that situation or if there is any best practice approach.
If you need more information, just let me know.
EDIT: I try to give a short example. The program can run in two different modes. Each mode has the same workflows but they differ slightly in the two modes. One workflow is about loading another assembly and setup communication between both programs. In both modes I have to call functions that are not needed in the other mode. Also this calls appear in other parts of the program.
These chunks are always about calling some functions at the right time in the correct order.
void WorkflowXY()
{
Foo.Do();
Foo.DoMore();
if(Mode.A)
{
//Chunk1, several lines of code, mostly calling other functions
}
else
{
//Chunk2, several lines of code, mostly calling other functions
}
}
void SomewhereElse()
{
//Code
//Chunk2
//more code
}
void InACompletlyDifferentNamespace()
{
//Code
//Chunk1
//more code
}
Avoid Helper classes, if you can. They're clear SRP violations and tend to become dumping grounds for loosely related methods.
I favour your second option. IMHO, classes cannot be too small. One class, one job.
This is worth a read.
Your "chunks of code" is a little bit unclear. Anyway, consider another question concerning static vs non static. It mentions also an extension method. If you do not wanna apply extensions, then another issue could fit for your purpose.
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 often confused by this. I've always been taught to name numbers I use often using variables or constants, but if it reduces the efficiency of the program, should I still do it? Heres an example:
private int CenterText(Font font, PrintPageEventArgs e, string text)
{
int recieptCenter = 125;
int stringLength = Convert.ToInt32(e.Graphics.MeasureString(text, font));
return recieptCenter - stringLength / 2;
}
The above code is using named variables, but runs slower then this code:
private int CenterText(Font font, PrintPageEventArgs e, string text)
{
return 125 - Convert.ToInt32(e.Graphics.MeasureString(text, font) / 2);
}
In this example, the difference in execution time is minimal, but what about in larger blocks of code?
When they say "use constants" they literally mean "use constants"; they do not mean "use variables that never change".
This is equivalent to your code:
const int recieptCenter = 125;
int stringLength = Convert.ToInt32(e.Graphics.MeasureString(text, font));
return recieptCenter - stringLength / 2;
With the const keyword in place, the compiler knows that 125 will never change, and will be able to apply the optimizations that it would apply to a constant expressed as a literal.
There is a huge advantage to naming your "magic numbers": people who maintain your code after you leave the company would know what's the meaning of 125. It will help you, too, when you come back to revisit this code in a few years.
The difference between using variables and hard-coded values is going to be negligible at worst. Compilers deal with things like this quite well. If you saw a difference in performance I would like to hear about your methodology for collecting those metrics. (Your test itself may be suspect and most likely not repeatable.)
In any case, you should first worry about making your program correct and maintainable. That means:
Carefully naming your classes, methods and variables
Separating concerns
Avoiding magic numbers and strings (What the heck is 125 and what does it mean?)
Avoid harcoding
etc.
Also, receiptCenter does not sound like it should even be a constant. It may change infrequently but I would suggest that you store it outside of your app in a config file, or db table etc. If that value ever needs to change you have to recompile and push the whole thing to prod. Also, what about publishing your software in some other place where the value of receiptCenter is different? You just want to change a config setting, not build a different version of the app just for that instance.
Optimization is the last thing you worry about, unless it's the first thing you have to worry about and that's an architect/expert-level consideration.
receiptCenter should be a constant declared somewhere outside that private method, in some obvious place, where all your constants are declared together. Alternatively, it could be a variable read from configuration.
It really does not improve your code when you give a name to a constant number somewhere in a private method deep inside of your class library.
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
Is it best practice to place method bodies before or after they are called ? I generally place them after; interested in what others are doing ?
I prefer after. The reason for this is because it makes the flow of your code more logical. Code flows from top to bottom anyway, so it's logical that methods called appear after the current method.
This has the added advantage of the entry point of your program/class being at the top, which is where you start looking anyway.
When developing Java, I place the method bodies after they are called. This will typically result in classes that have a small number of public methods at the top, followed by quite a few private methods at the bottom. I think this makes the class easier to read and understand: you just need to read those few public methods at the top to understand what the class does — in many cases you can stop reading once you get to the private methods.
I also note that Java IDEs typically place the method body after the current method when you refactor code. For example in Eclipse, if you select a block of code and click Refactor | Extract Method... it will place that selected code in a new method below the current one.
It is entirely a matter of personal preference. For most people, the code navigation facilities of a modern IDE mean that it hardly makes any difference how the methods are ordered.
The method placement is largely irrelevant to me (of course in case of some static methods that need to be defined before invoked):
The code formatters are usually in place (and running automatically - if not for you, turn them on) which results in the source being ordered nicely by type of the method and then alphabetically, rather without the regard to the method call sequence
I use the modern IDE, where finding the proper method is done in a different way than sequentially going through the whole source