|
Christian Brüggemann wrote: my colleague
You surely mean ex-colleague. By rough estimations, he should have been shot a few times
|
|
|
|
|
|
var tomorrow = new DateTime(2012, 4, 26);
Fixed the comment for you
|
|
|
|
|
Just 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(); }
}
|
|
|
|
|
When I see stuff like this I genuinely don't know whether to laugh or cry!
|
|
|
|
|
Here's one person that believes coding languages do evolve.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
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!
|
|
|
|
|
#if DEBUG
#else
#endif anyone?
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
#else
#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.
|
|
|
|
|
Looks like someone found a way to stop time.
|
|
|
|
|
Should it have been:
var tomorrow = new DateTime(2012, 2, 3);
var today = "Groundhog Day";
|
|
|
|
|
if (wttResultsDataTable.Rows.Count == 1000)
{
if (wttResultsDataTable != null)
{
if (wttResultsDataTable.Rows.Count > 0 && DCTReportRoot.errorFlagRaised == false)
{
Besides the fact, the code would blow up before this point if wttResultsDataTable was null, wouldn't the first if blow up if it was null?
|
|
|
|
|
Nice piece of work, if wttResultsDataTable is really null application will fail in the first place
|
|
|
|
|
You cannot be sure... In a multi-threading environment, something bad might happen to the wttResultsDataTable during the calls. Better safe than sorry!
|
|
|
|
|
You are quite right. The code should be
lock(global_lock_object){
if (wttResultsDataTable.Rows.Count == 1000)
{
if (wttResultsDataTable != null)
{
if (wttResultsDataTable.Rows.Count > 0 && DCTReportRoot.errorFlagRaised == false)
{
|
|
|
|
|
I'm not sure he is being quite cautious enough.
Surely he should add a test to ensure that 1000 is a positive number?
if (!(1000 < 0))
{
...
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
You're still taking way to many risks there... Before checking that you should check if false is not true!
if (false != true) { ... The Mayan calendar ends soon, so you'll never know what might happen... At least THIS software won't break
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}
|
|
|
|
|
I remember one FORTRAN compiler (GEC 4070 IIRC) where you could write the equivilent of this:
if (1==1)
statement 1
else if (1!=1)
statement 2
else
statement 3 with pretty good confidence that each of the three statements would be executed at some point...
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
OriginalGriff wrote: with pretty good confidence that each of the three statements would be executed at some point I'd love to argue that with you, but I've worked with FORTRAN before. I've seen code I'd swear was dead and refused to remove it just because I've seen things that can't happen, proceed to do so in that language.
|
|
|
|
|
Yeah - COMMON was a good source of "oddities".
I have seen COMMON used to declare a variable as a single integer, and use it as a multidimensional array of floats...
We used to say "Don't like the OS? Use FORTRAN, and change it!"
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
OriginalGriff wrote: "Don't like the OS? Use FORTRAN, and change it!"
You've just reminded me of my first ever hack. Back in 1964 or thereabouts at Monash Uni, they had a "state of the art" CDC 3200 to which we were allowed to send decks of punched cards. A day or so later, the deck reappeared, hopefully wrapped in a couple of pages of printout. We mere undergrads were limited to IIRC 30 secs run time, which became a bit of a limit on some of our "foreign orders". So, based on a knowledge of the constant absolute address of blank common and a bit of spelunking (find locations in the OS that changed more or less linearly with time...), I wrote an innocent looking FORTRAN subroutine that reset the job timer if it was close to running out. Oh, the joys of unchecked negative array indexes!
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|