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
Is there any reason to use one of these techniques over the other?
There are several strings that get created in the code behind:
protected string String1;
protected string String2;
protected string String3;
protected string String4;
They are used in the front end code and can be printed to the screen using:
<%#String1%><%#String2%><%#String3%><%#String4%>
Alternatively these can be printed using:
<%#String1 + String2 + String3 + String4%>
The second technique seems a little easier to read. The thought popped into my head that it may be slightly less efficient depending on how the <#%%> is evaluated compared to the +.
Is there a difference in efficiency that makes one way better than the other?
Well, for the second case it'll be transforming that code into a single call to string.Concat, which is as efficient of a method as you can get for concatting 4 C# strings together.
I'm not positive how ASP goes about taking each component of the markup and building a single string out of the content, but I would be shocked to find out that it used a silly strong concatenation method that ends up building an intermediate string and copying over the entire page's HTML every time a new component is added in. I think it's a pretty safe bet to assume that some reasonably sensible method is used, most likely either StringBuilder, writing the content to a stream, or some other comparable method of efficiently appending a series of strings together.
Asp.net engine will not concat the following string to each other it just render 4 times and place it in the html code
<%#String1%><%#String2%><%#String3%><%#String4%>
While below string will concat on server side and render 1 time only. definitely this is easy to read and understand.
<%#String1 + String2 + String3 + String4%>
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 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 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'm returning a string from an API that has a length of 45 characters. There is one word that is unique for one condition that doesn't appear in the other condition.
I'm wondering if using string.contains() is faster performance-wise than comparing the whole string with string.equals() or string == "blah blah".
I don't know the inner workings of any of these methods, but logically, it seems like contains() should be faster because it can stop traversing the string after it finds the match. Is this accurate? Incidentally, the word I want to check is the first word in the string.
I agree with D Stanley (comment). You should use String.StartsWith()
That said, I also don't know the inner working of each method either, but I can see your logic. However "String.Contains()" may still load the entire string before processing it, in which case the performance difference would be very small.
As a final point, with a string length of only 45 characters, the performance difference should me extremely minute. I was shocked when I wrote a junky method to substitute characters and found that is processes ~10kb of text in a fraction of a blink of the eye. So unless you're doing some crazy handling else wise in your app, it shouldn't matter much.
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 7 years ago.
Improve this question
Someone told me to place my entire application strings in const instead of inline.
Why is that?
Does it improve compilation time? run time? or just code standard?
example
instead of writing:
selectSingleNode.InnerText == "SomeString"
write
selectSingleNode.InnerText == SOME_CONST
You would do this purely for maintainability and readability. Using a named constant instead of a string literal will have no performance impact whatsoever.
Maintainability
If you have multiple places in the code that require the same string literal, having them all use the same named constant makes your code a lot more maintainable. If you ever decide you need to change the value of the string literal, there is only one place you need to make the change.
Readability
Even if your string literal is used in a single place, providing a named constant may make your code more readable.
For instance, in the following sample, which version do you feel conveys the intent more clearly?
// string literals
int startIdx = someString.IndexOf("[");
int endIdx = someString.IndexOf("]");
// vs. named constants
int startIdx = someString.IndexOf(TAG_START);
int endIdx = someString.IndexOf(TAG_END);
A properly chosen name for a constant can make the code's intent clearer. But the key here is that you have to pick a good name. Too often, I'll see things like:
private const string ASTERISK = "*"; // very poor name
That is a very poorly chosen constant name that doesn't help readability one bit. The problem is that it simply states the contents of the string literal, when instead, it should be communicating what the string literal is used for.
I've seen some tests where developers have tested execution time and IL generated between using const and non-const strings. It's true there is the slightest of performance gain from using const (though insignificant unless you're working for nasa or Wall Street) the real benefits are:
You are ensuring your values are immutable.
You are defining literals in one location instead of writing them inline. If you need to change a value in the future it should be easier.
This isn't exhaustive and I'm anxious to see what others post as well. Hope this at least helps.
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 the best memory efficient/efficient way to declare string and other data type variables in c#!?
Option 1
string strAssociateId = context.Request.QueryString["xxxxxx"],
strAssociateName = context.Request.QueryString["xxxxx"],
strPhoto = context.Request.QueryString["xxxxx"],
strDescription = context.Request.QueryString["xxxxx"];
or
Option 2
string strAssociateId = context.Request.QueryString["xxxxx"];
string strAssociateName = context.Request.QueryString["xxxxx"];
string strPhoto = context.Request.QueryString["xxxxx"];
string strDescription = context.Request.QueryString["xxxxx"];
or
any other way!?
which is the best way to follow on a longer run?!
or both have the same efficiency!?
downvoters pls comment so that i can correct.
I am just trying to find the best way and this question is not there in stackoverflow before!!
this will not lead to any discussion, and the question is completely answerable and clear
The only difference between those options, is readability. There are no performance difference, and they will generate the exact same IL.
For readability, I would choose option 2.
They will be compiled to the same IL, your Option 1 is simply syntactic sugar.
I my opinion Option 2 is better because it has better readability.
which is the best way to follow on a longer run
Both are best as both will generate the same IL.
or both have the same efficiency
Yes as both have same efficiency.
Which one to follow
You need to follow the one that is followed through out your application to support consistency. However if you are starting a new project you can decide not which one you like the most. My preference is the second one as it is more common as well as more readable
Both are better. But you are gonna mess up with the code. If you prefer using second method you might require or consider using comments
// this code is this..
So that you can know what variable or string was written here. Either you might think that this is a parameter to something.
The first method is more lovey to everybody. However I don't use strings. I use simple vars.
To follow a long run, you can use any of them. They don't have any time consuming effect.
To check more about these You can use IE F12 Developer Tools. To Test which page is using more time to get loaded.