|
I have just copy pasted what was there and thats the reason this is in weird and wonderful...
"When you don't know what you're doing it's best to do it quickly"- SoMad
|
|
|
|
|
FUD* rules! You don't want to take it out, because it MAY do something. What if in it's nothingness it does a something?
Hahaha - Besides, who cares? No one pays me to remove code. Do they?
I'm trolling for people who think I'm serious. Are you one of them?
*FUD - Fear, Uncertainty, Doubt
|
|
|
|
|
Actually it does something: it reads Enddate, which may cause an access violation if it was called on an invalid object. I'm not sure what language that is from, so maybe it isn't possible to have an invalid object in the list, but then the entire list could be invalid, no?
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Indeed, get rid of the var and replace it with the actual type.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
People were paid to make my compiler do that. And it does.
|
|
|
|
|
If an objective does not have a defined end-date
Process accordingly
else
Process the objective with a defined time range
And that is weird and wonderful how?
Assuming of course that you have stripped out the processing logic...
|
|
|
|
|
Tim Carmichael wrote: Assuming of course that you have stripped out the processing logic
And thats the place you were wrong. Now you understand why this is in weird and wonderful....
"When you don't know what you're doing it's best to do it quickly"- SoMad
|
|
|
|
|
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
|
|
|
|