|
Pualee wrote: if the queries are in the code rather than stored procedures
I never mentioned stored procedures . Parameterized queries can be kept in the source code.
|
|
|
|
|
For me, writing on this forum is always a tradeoff between looking stupid and learning more...
Thanks for the clarification
|
|
|
|
|
We use Stored Procedures at the organization I work for, but they have to be created in VS (which is under Source Control) before they can be created on the test database (with each release we submit release notes with files we've modified, created or removed and the person responsible for the builds handles it from there) that way the stored procedures are also under source control.
"Okay, I give up: which is NOT a real programming language????"
Michael Bergman
"Well yes, it is an Integer, but it's a metrosexual Integer. For all we know, under all that hair gel it could be a Boolean."
Tom Welch
"Let's face it, the average computer user has the brain of a Spider Monkey."
Bill Gates
|
|
|
|
|
Or.... just write a function to check all your input fields before processing them? Little things... like making sure numeric values are in "int" and strings are properly quoted out and escaped before concatenating the final SQL string works fine too. Just gotta be careful.
|
|
|
|
|
First code snippet
<br />
for(int i=1;i<=100;i++)<br />
DropDownList1.Items.Add(new ListItem(i.ToString(),i.ToString()));<br />
Second Code Snippet
<br />
DropDownList1.Items.Add(new ListItem("1","1"));<br />
DropDownList1.Items.Add(new ListItem("2","2"));<br />
DropDownList1.Items.Add(new ListItem("3","3"));<br />
DropDownList1.Items.Add(new ListItem("4","4"));<br />
DropDownList1.Items.Add(new ListItem("5","5"));<br />
DropDownList1.Items.Add(new ListItem("6","6"));<br />
DropDownList1.Items.Add(new ListItem("7","7")); <br />
DropDownList1.Items.Add(new ListItem("8","8")); <br />
.<br />
.<br />
.<br />
.<br />
DropDownList1.Items.Add(new ListItem("99","99")); DropDownList1.Items.Add(new ListItem("100","100"));<br />
<br />
Regards,
Sylvester G
sylvester_g_m@yahoo.com
|
|
|
|
|
not really the right forum for this.
but.
methink the first alternative is the simplest, the fasted and can be the easiest to maintain in the long run.
|
|
|
|
|
If you'd posted the second as an example of what somebody has done then I would say this was a perfect coding horror.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
It happened long time back with one of my friend, He was working in a company and his colleague wrote all hundred lines of code to populate drop down listbox.
Regards,
Sylvester G
sylvester_g_m@yahoo.com
|
|
|
|
|
I can see how this could be done in a script language, where there is no benefit to keeping the data outside of the application, i.e. actually use the multiple statements to define the content of the list.
|
|
|
|
|
sylvesterg wrote: wrote all hundred lines of code to populate drop down listbox.
And if that is JavaScript, the amount of page size (ViewSource) that travels down the Internet pipe is really phenomenal.
|
|
|
|
|
The first one is much better coding.
The second one I would predict to be a nanosecond or something faster.
The reason being the first one has to create a loop, some tostrings, an int etc....
And it still creates the same ammount of listitems, and such.
The second on would make a larger dll, but probably execute a smidget faster cause of less resources..... but.... NEVER EVER DO THAT unless you have like 2 items or something small and ridicuous.
The performance difference is not even close to being worth the pain of working on code like that.
So... for(...) wins hands down.
http://www.jonavi.com
|
|
|
|
|
There's usually an unroll-loop option in most compilers.
|
|
|
|
|
The first one is certainly slower, since the compiler will have to evaluate two additional commands for every loop... but is certainly better in terms of maintainability.
|
|
|
|
|
The second one is faster I think (with a couple of µs that is)
The first one is far, far better.
V.
I found a living worth working for, but haven't found work worth living for.
|
|
|
|
|
Any improvement in speed the second may have pales in comparison to the cost in maintainability.
Any why have both values be strings?
And why have a DropDownList simply to select a number? Use a NumericUpDown or a TextBox with validation.
I really dislike Websites that have a list of (U.S.) state abbreviations or whatnot when it's simpler just to type in the data... e.g. I now live in Arizona, but rather than allowing me to enter "AZ" (two keystrokes) I need to either scroll down or press "A" five times! Just so the programmer doesn't have to validate the entry, pathetic.
|
|
|
|
|
sylvesterg wrote: which one is faster
It is easy to check: just make a loop with a couple of million items to add, and then type the second version up to the same number, and you'll be able to measure it with a stopwatch.
|
|
|
|
|
The best is use make an array with the strings and after use items.AddRange, and also for Painting part.
|
|
|
|
|
I'd go with the first as being better. Besides, the overhead in "DropDownList1.Items.Add()" itself is enough to mask any possible speed difference between the two constructs. Really, both should execute fast enough that you won't notice it anyway. Speed diff can be so easily lost due to random interrupts and kernel scheduling variations that it becomes a "who cares" issue for the most part.
And the explicit one... what a nightmare to maintain.
|
|
|
|
|
The first is the better because it is more readable and bug-safer. In the second you have to paste and copy too much.
I would write
String s;//here
for(int i=1;i<=100;i++)
{
const String s = i.ToString();//could be best, so let the compiler do the optimzing !!!
DropDownList1.Items.Add(new ListItem(s,s));
}
so I win one call
The first one is the best for the programmer - so what second
Greetings from Germany
|
|
|
|
|
Would it be better to do the call to i.ToString() only once and assign it to a variable?
Being in a minority of one, doesn't make you insane George Orwell However, in my case it does
|
|
|
|
|
The latter method is somewhat like C++ inline qualifier for function right?
|
|
|
|
|
First, you are not supposed to ask questions here.
Now, on modern day machines it does not matter that much. The second would be faster, at least it use to be and is called unrolling. In the old days the difference would be noticeable by the user and is why unrolling loops was sometime needed, especially in graphics applications. In this case the new operation is more of a bottle neck than the loop, but pre-allocating memory space can help solve that problem.
Any way,
Just use the loop form, as it is easier to maintain and you probably do not have a legitimate reason not to.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
Recently a contractor(my View about Contractors - are supposed to good programmers!) worked in our project.
Code written in C#-VS2005
He wrote
<br />
public void RegisterEvents()<br />
{<br />
obj.CenterChanged += new CenterChangedEventHandler(OnCenterChanged);<br />
obj.CenterChanged += new CenterChangedEventHandler(OnCenterChanged);<br />
}<br />
My question:
Would registering the same event twice call the handler twice when event is raised?
-rt
|
|
|
|
|
I did a quick check myself and indeed the handler gets called twice if registered twice.
The handler handled some drawing code which I am sure would redraw twice!
|
|
|
|
|
Contractors aren't magic bullets for organisations. Like every other profession, some are good and some are bad. Remember that a lot of people are attracted to contracting for the perceived high remuneration and you can see why there is a lot of chaff among the wheat.
Deja View - the feeling that you've seen this post before.
|
|
|
|