|
It took me a while to realize that you haven't removed any code in if/else block.
|
|
|
|
|
And as soon as you remove the obviously-meaningless loop, you'll learn two things:
1) objectivesLst is actually an IEnumerable that, when enumerated, writes pieces of its contents to ten different parts of the application for later use. Suddenly, you have NullReferenceExceptions coming out of your ears...
2) Accessing the EndDate property sets a global variable that's later used to prevent the application from reformatting your hard drive.
Unfortunately, you'll learn these too late to save yourself, and will instead begin an epic journey to find whoever wrote the code and beat him to a pulp 
|
|
|
|
|
Funny, but possibly true. I've had similar things happen. 
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
|
PIEBALDconsult wrote: But then the main developer decided to become clever and use Reflection to populate the User objects, and now it takes a half hour.
1) Reflect once to get the property list
2) Use LINQ Expressions to compile mutators in memory
3) ???
4) Profit!
|
|
|
|
|
1) Yes, if I had known what he was doing I would have suggested it, but I didn't know until after he left. He probbaly wouldn't have taken my advice though because "it works". It's that he removed good code and replaced it with bad code that really gets me.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Had you started your list correctly, at index 0, you'd have seen that it'd be three steps.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: it'd be three steps
Gimme three steps. Gimme three steps, mister...
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Don't even have to be that clever, just caching the result of reflection calls in a Dictionary<string, PropertyInfo> takes away all the slowness. I've had to do that a few times over the years.
Linq Expressions lets you write arguably more elegant code to do it, but might be a bit hard to get an incompetent developer to understand 
|
|
|
|
|
That makes it faster, but you're still adding boxing/unboxing, since PropertyInfo.Invoke() isn't strongly-typed. Not significant in small doses, but call it a few thousand times with primitive types and you'll notice a difference. My current implementation feeds the columns in a custom-made data grid, and that can seriously add up.
|
|
|
|
|
That's true but I've done something similar (model-view binding into a data grid where the columns are based on properties of the data objects) and it was easily fast enough once I cached the PropertyInfos.
I'm not saying you are wrong (you're not, your solution is better), just that you don't need to go to that level to get most of the benefit.
|
|
|
|
|
No, no, no. You got it all wrong. The EndDate property does actually important part of work here and the if{..}else{..} is there to prevent that pesky optimizer from removing useful code
But if by any chance it really is that way, you better start to look for a good gun and a good lawyer...
--
"My software never has bugs. It just develops random features."
|
|
|
|
|
Sometimes long running loops are solving race conditions ;D
If you remove this code, the method is executed faster and suddenly nothing works anymore!
(Real world example!)
|
|
|
|
|
Did the guy face some problems with lazy loading?
The optimizer might remove an empty foreach, hence he accesses a property of every item.
Why not create a ForceLoad function in the list, and call it? - Well, obfuscating the intent of some code is such a great idea.
|
|
|
|
|
It's invisible NSA code
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
It's official - I have too many eBooks to cope with without help, so I decided to knock up a quick SQL DB app to organise them (and play with creating a new DataGridView based UserControl with automatic fuzzy filtering).
So I've just spent the last hour or so wondering where my data is / was / should be:
string[] files = Directory.GetFiles(path, "*.*", SearchOption.AllDirectories);
IEnumerable<Book> books = files.Select(f => new Book(f, path));
Author.SaveAllNew();
Series.SaveAllNew();
Book.SaveAllNew(); The Book constructor determines the Series and Author and creates them as needed.
So where is everybody? My DB is still empty...
...later.
...much later.
...until I remembered Linq methods use deferred execution, that is... 
string[] files = Directory.GetFiles(path, "*.*", SearchOption.AllDirectories);
IEnumerable<Book> books = files.Select(f => new Book(f, path)).ToList();
Author.SaveAllNew();
Series.SaveAllNew();
Book.SaveAllNew();
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
:confusedFaceAtMisleadingTitle:
|
|
|
|
|
Assuming you're using .NET 4.0 or higher, Directory.EnumerateFiles[^] is more efficient than Directory.GetFiles[^], as it doesn't have to allocate an array to contain every file path.
Also, unless you specifically want to filter out files without extensions, use "*" instead of "*.*" as your search pattern.
And since you don't seem to be using the result of the ToList call, it would probably be better to avoid creating a list. Unfortunately, there's no built-in Consume method, but it's not hard to write one:
public static class NomNomNom
{
public static void Consume<T>(this IEnumerable<T> source)
{
if (source == null) throw new ArgumentNullException("source");
foreach (T item in source);
}
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I use the list later on for UI updates - I just didn't show that part!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
One does not simply lecture OG on programming . 
Microsoft ... the only place where VARIANT_TRUE != true
|
|
|
|
|
Oh, come on! He describes himself as the CEO of Wales. When was the last time you met a CEO who knew the first thing about writing code? 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: When was the last time you met a CEO who knew the first thing about writing code?
I couldn't know after all I work as a code monkey. I don't meet such people like CEOs.
But your post was funny 
Microsoft ... the only place where VARIANT_TRUE != true
|
|
|
|
|
Argonia wrote: I don't meet such people like CEOs
Undo another button or two.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
He can if he wants - I make mistakes like everyone else, and am both very aware and very thankful that I don't know everything.
Mind you, I did know everything when I was 18...
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
OriginalGriff wrote: when I was 18...
That was surely before the dawn of men (and thus before the age of the personal computer) 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
