|
I just know that in a years time I'm going to look at that line of code and go "What? Why?"
Perhaps I can head myself off at the pass!
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 – ∞)
|
|
|
|
|
Sometimes it is easy to understand by looking at the code rather than the comment. There are such programmers.
|
|
|
|
|
I write comments like that too, especially if I have to do something that isn't obvious as to WHY I'm doing it. (Usually because the client is asking for something that's just the opposite of what they wanted six months ago.)
It also lets other people know to think twice before changing that code willy-nilly.
|
|
|
|
|
That's fine. Documentations are always longer than codes.
Don't mind those people who say you're not HOT. At least you know you're COOL.
I'm not afraid of falling, I'm afraid of the sudden stop at the end of the fall! - Richard Andrew x64
|
|
|
|
|
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.
|
|
|
|