|
Someone has probably pointed this out already, but since the end result of this function is that the list is emptied, there's no need to remove one element at a time. So instead:
foreach (double temp in fakeList)
{
}
fakeList.RemoveAll();
But then, I don't have a C.S. degree...
|
|
|
|
|
Although I completely agree with this is being a bug in the viewpoint of performance. I am reluctant it say never use this construct. I can see instance where it could be used. How about a Push/Pop type of utilization of the list? FIFO (First In First Out)?
While at it's core it is less efficient; The question would be utilization? What is the unknown it's the //.. do something portion of the logic? What's it doing?? Is it going to take more that 5 seconds (based off a previous message)? Does the extra processing outweigh this performance hit? Can it ever break out the loop so fakeList.Clear() cannot be use? What about if I really need to go down the list and not up, and walking backwards isn't an option?
I'm not very familiar with C#, so I cannot comment on List vs LinkedList and performance. However, sometimes there is a rational which a code was used. Sometimes it's just wrong. I have used this construct before, and still don't think it was incorrect, yet I wasn't working with a 10k or 100k list. Just my two cents, IMHO..
|
|
|
|
|
I love them but, alas, the previous developer did not. There was a small, almost inconsequential "if" statement, not unlike:
if(some_condition) do_some_action;
At some point, the Nameless One, either through accident or lack of testing or malice, I know not which, changed it to:
if(some_condition) ; do_some_action;
Essentially, a null statement. I only discovered this when one of our test engineers mentioned that something he was testing seemed to give different results to what he was expecting. I eventually found the problem and thankfully, ReSharper's suggested change alerted me to it. I'm not saying that the use of braces protects you from all problems but I sure wish the previous chap had used them. I've long known the code is a mix of braces and no braces where "if"s are concerned but the inconsistency has long driven me nuts. Sadly, one came home to roost this morning. I'm sure it won't be the last.
|
|
|
|
|
Braces do not protect you.
Only a few weeks ago, I had:
if (bSomeFlag);
{
SomeCodeWhichAlwayRan ();
}
I was tired!
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
correct. the braces don't protect you from the situation that was reported. what they do protect you from is someone later adding another statement inside there and forgetting to add the braces at that time.
|
|
|
|
|
There is no protection from stupid.
Failure is not an option; it's the default selection.
|
|
|
|
|
Iain Clarke, Warrior Programmer wrote: Braces do not protect you.
But using warning level 3 or 4 do so by giving you an informational C4390.
|
|
|
|
|
And that informational would have helped the original poster too, surely?
I'm not saying braces are a bad idea - I use them after almost every if myself, just that they have no effect on the originally posted issue.
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
I agree with you and him to use braces. But the warning would be also thrown for his example (provided it is C/C++).
|
|
|
|
|
Similar tot he below issue, an example of which was posted on CP about a month ago
if(some very long condition that pushes the right hand side of the statement off the screen) return;
{
}
It is likely the extra return was a temporary debugging thing that got left as a dingleberry ... but a subtle bug none-the-less.
I personally always use braces and think it a shame that the above example compiles at all
Pedis ex oris
Quidquid latine dictum sit, altum sonatur
|
|
|
|
|
Wouldn't that then make a case for starting braces next to the very first statement?
if (xxx){
Of course some would argue that makes the start and end brace difficult to spot 
I are n00b.
|
|
|
|
|
Agreed. I ALWAYS use braces, also for single if/else/for/... statements.
And when I see something like this:
if
else if
else if
else if
else if
...
Well,... explaining that would not be KS safe. 
V.
|
|
|
|
|
That is one of the reasons why I always run with "treat warnings as errors":
Warning 1 Possible mistaken empty statement
I can't run my code with that in there.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
Agreed. I'd love to use that option but that too has a sting in the tail. Unfortunately, he used more classes in the uber-project than I ever had classes at school and when I say it compiles with over 120 warnings, I'm not kidding. Some are easily rectifiable but there are others that are more sinister and which the compiler barfs about objects hiding those in the base class to name but one example. I'd love to select all the code and let Resharper reformat and correct it for me but I'm genuinely reluctant to do it. Some of the many 1000s of lines of code in a single file (yup, such files exist) contain 100s of Resharper suggestions to change and refactor. I really love Resharper, but I can't sleep easy knowing it might well clean the code too well that it breaks it.
I don't subscribe to the "if it compiles clean, go live" paradigm but this project is one where it's best to let the proverbial canine sleep where it is. 
|
|
|
|
|
You got crooked teeth or something?
|
|
|
|
|
Yeah, I've done that. I've learned -- the hard way, I will admit -- to ALWAYS use braces in C-derived code (C, C++, C# and Javascript.) They do not change the size or efficiency of compiled code and can be very helpful in tracking down bugs. I even go so far as to put all of my braces on their own line, with their own level of indentation: I can then print out the code, pull out a pencil and a ruler, and make sure everything lines up properly. For client-side script, I keep a working copy that's formatted and then compress it when it goes onto the server.
|
|
|
|
|
PHS241 wrote: I love them
I prefer belts!
(Well someone had to say it!  )
"State acheived after eating too many chocolate-covered coconut bars - bountiful"
Chris C-B
|
|
|
|
|
PHS241 wrote: I love them but, alas, the previous developer did not. There was a small, almost inconsequential "if" statement, not unlike:
I was convinced when my coworker recounted horror stories of adding a line in Fortran that was the equivalent of something like this:
if (fooIsTrue)
DoSomething();
DoSomethingMore();
Conversely, I once spend half a day debugging the equivalent of:
int i;
for (i=0; i<100; i++);
{
printf(i);
}
and wondering why the result was 100 (or more precisely, why the loop only executed once!)
Marc
|
|
|
|
|
I used to hate brackets. Every character you can eliminate from code is one less that can cause a bug.
Then, like so many others, I wasted time debugging bugs like this:
if(whatever)
dosomething()
dosomethingElse()
Now where I work, we require brackets on everything, no matter what. It turns what could have been a 1-line IF into 4 lines, but if it avoids even one future bug, it is well worth it!
BTW, the semicolon after the if, in VS2010 C# at least:
if(whatever) ;
{
...
}
Gives me a "Possible mistaken empty statement" warning when I build. Dang that thing is smart. Now if it would just fix it for me and not bother me with the warning at all...
|
|
|
|
|
 Don't need braces at all.
If [your condition here]
Your code here
End If
Schenectady? What am I doing in Schenectady?
|
|
|
|
|
The braces aren't the problem here, the lack of a test framework is.
|
|
|
|
|
I like braces but some of my co-workers don't so I learn to live with that... 
|
|
|
|
|
I notice in a number of posts this morning with comments about receding hairlines, etc. It seems to me to be a poll survey begging to be conducted:
Describe the state of your scalp:
- Blessed With Youthful Follicular Profusion
- Viewed from above, your basic bulls-eye
- My eyebrows still look great if that's what you mean
- Gravity Won Out - It now all resides upon my chin
- I console myself knowing that bee's wax is cheaper than shampoo
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I am an egg-shell blond. 
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
Was that crack just hatching a plot to make some sort of yolk?
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
