var tomorrow = ?
-
Found this in my colleagues' code today. We had a good laugh on that :)
\\ some code
var item = values.TryGet(3);
var dt = (DateTime)values[0];
var tomorrow = new DateTime(2012, 4, 26); // DateTime.Today.AddDays(1);if(item != null)
\\ some more codeJust one error I see in there...
var twentySixthAprilTwoThousandAndTwelve = new DateTime(2012, 4, 26);
FTFY :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
Found this in my colleagues' code today. We had a good laugh on that :)
\\ some code
var item = values.TryGet(3);
var dt = (DateTime)values[0];
var tomorrow = new DateTime(2012, 4, 26); // DateTime.Today.AddDays(1);if(item != null)
\\ some more codeWhen I see stuff like this I genuinely don't know whether to laugh or cry! :sigh:
-
When I see stuff like this I genuinely don't know whether to laugh or cry! :sigh:
-
Found this in my colleagues' code today. We had a good laugh on that :)
\\ some code
var item = values.TryGet(3);
var dt = (DateTime)values[0];
var tomorrow = new DateTime(2012, 4, 26); // DateTime.Today.AddDays(1);if(item != null)
\\ some more codeYou won't believe it but I found very similar line in our code a few days ago, just the variable name was "yesterday" and it was set to May 22. :-D
-
You won't believe it but I found very similar line in our code a few days ago, just the variable name was "yesterday" and it was set to May 22. :-D
-
Found this in my colleagues' code today. We had a good laugh on that :)
\\ some code
var item = values.TryGet(3);
var dt = (DateTime)values[0];
var tomorrow = new DateTime(2012, 4, 26); // DateTime.Today.AddDays(1);if(item != null)
\\ some more codeBut, hey, it worked without errors when he wrote and debugged it on April 25th. Actually it looks like it might have been used to trigger some event on the 25th - but for only 2012? Scratch that! Why code to look for tomorrow instead of today. I'm through trying to rationalize this. I guess I try to assume there is a reason for everything and people are better then they really are. :wtf: Hope it wasn't moved into production.
-
Found this in my colleagues' code today. We had a good laugh on that :)
\\ some code
var item = values.TryGet(3);
var dt = (DateTime)values[0];
var tomorrow = new DateTime(2012, 4, 26); // DateTime.Today.AddDays(1);if(item != null)
\\ some more codeLooks like someone found a way to stop time.:cool:
-
Humm, must be a new pattern. ;)
Just because the code works, it doesn't mean that it is good code.
Or the same employee, different company.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
Found this in my colleagues' code today. We had a good laugh on that :)
\\ some code
var item = values.TryGet(3);
var dt = (DateTime)values[0];
var tomorrow = new DateTime(2012, 4, 26); // DateTime.Today.AddDays(1);if(item != null)
\\ some more codeShould it have been:
var tomorrow = new DateTime(2012, 2, 3);
var today = "Groundhog Day"; -
But, hey, it worked without errors when he wrote and debugged it on April 25th. Actually it looks like it might have been used to trigger some event on the 25th - but for only 2012? Scratch that! Why code to look for tomorrow instead of today. I'm through trying to rationalize this. I guess I try to assume there is a reason for everything and people are better then they really are. :wtf: Hope it wasn't moved into production.
Simple rationale - running this on a test system and the last day that the test system has data for is 4/26. A quick change to the code for debug purposes, just make sure to roll it back before release... oops!
-
Simple rationale - running this on a test system and the last day that the test system has data for is 4/26. A quick change to the code for debug purposes, just make sure to roll it back before release... oops!
#if DEBUG
//DEBUG CODE
#else
//RELEASE CODE
#endifanyone?
public class SysAdmin : Employee
{public override void DoWork(IWorkItem workItem) { if (workItem.User.Type == UserType.NoLearn){ throw new NoIWillNotFixYourComputerException(new Luser(workItem.User)); }else{ base.DoWork(workItem); } }}
-
#if DEBUG
//DEBUG CODE
#else
//RELEASE CODE
#endifanyone?
public class SysAdmin : Employee
{public override void DoWork(IWorkItem workItem) { if (workItem.User.Type == UserType.NoLearn){ throw new NoIWillNotFixYourComputerException(new Luser(workItem.User)); }else{ base.DoWork(workItem); } }}
Zac Greve wrote:
#if DEBUG //DEBUG CODE #else //RELEASE CODE #endif
True, and I do that a lot. Though it's bit me a couple times that I now watch out for... a) In most situations I'd really rather have 3 levels - DEBUG on my dev machine, DEBUG on the dev server, RELEASE on the production server. b) Release code paths don't get tested as thoroughly until uploaded to the production server. I mean - you have to test them, but if you wrap everything in #if DEBUG directives, it can be nontrivial to run in VS on a dev system in RELEASE mode.
