|
foreach (var thisObjective in objectivesLst)
{
if (thisObjective.EndDate != null)
{
}
else
{
}
}
And this beauty lies inside one of the wonderful projects i came across.
I have not removed any code from the above snippet. This is part of the code which i found in completed project. This developer should really be awarded...
"When you don't know what you're doing it's best to do it quickly"- SoMad
modified 25-Jul-14 10:09am.
|
|
|
|
|
Is EndDate defined as a "DateTime? " (aka "Nullable<DateTime> ")?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: Is EndDate defined as a "DateTime? "
Whether it is or not, i loved the way this code was written...
"When you don't know what you're doing it's best to do it quickly"- SoMad
|
|
|
|
|
Are you saying that you didn't let out the code inside the if?
|
|
|
|
|
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.
|
|
|
|