Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. Other Discussions
  3. The Weird and The Wonderful
  4. var tomorrow = ?

var tomorrow = ?

Scheduled Pinned Locked Moved The Weird and The Wonderful
question
16 Posts 15 Posters 1 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • T Tom Chantler

    When I see stuff like this I genuinely don't know whether to laugh or cry! :sigh:

    S Offline
    S Offline
    SortaCore
    wrote on last edited by
    #7

    Here's one person that believes coding languages do evolve.

    1 Reply Last reply
    0
    • C Christian Bruggemann

      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 code

      F Offline
      F Offline
      Fedor Hajdu
      wrote on last edited by
      #8

      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

      B 1 Reply Last reply
      0
      • F Fedor Hajdu

        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

        B Offline
        B Offline
        BillW33
        wrote on last edited by
        #9

        Humm, must be a new pattern. ;)

        Just because the code works, it doesn't mean that it is good code.

        F 1 Reply Last reply
        0
        • C Christian Bruggemann

          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 code

          D Offline
          D Offline
          DarthDana
          wrote on last edited by
          #10

          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.

          C 1 Reply Last reply
          0
          • C Christian Bruggemann

            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 code

            T Offline
            T Offline
            Timothy J Sygitowicz
            wrote on last edited by
            #11

            Looks like someone found a way to stop time.:cool:

            1 Reply Last reply
            0
            • B BillW33

              Humm, must be a new pattern. ;)

              Just because the code works, it doesn't mean that it is good code.

              F Offline
              F Offline
              Fabio Franco
              wrote on last edited by
              #12

              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

              1 Reply Last reply
              0
              • C Christian Bruggemann

                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 code

                M Offline
                M Offline
                Member 2053006
                wrote on last edited by
                #13

                Should it have been:

                var tomorrow = new DateTime(2012, 2, 3);
                var today = "Groundhog Day";

                1 Reply Last reply
                0
                • D DarthDana

                  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.

                  C Offline
                  C Offline
                  Chris Berger
                  wrote on last edited by
                  #14

                  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!

                  B 1 Reply Last reply
                  0
                  • C Chris Berger

                    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!

                    B Offline
                    B Offline
                    Brisingr Aerowing
                    wrote on last edited by
                    #15

                    #if DEBUG
                    //DEBUG CODE
                    #else
                    //RELEASE CODE
                    #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);
                          }
                     }
                    

                    }

                    C 1 Reply Last reply
                    0
                    • B Brisingr Aerowing

                      #if DEBUG
                      //DEBUG CODE
                      #else
                      //RELEASE CODE
                      #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);
                            }
                       }
                      

                      }

                      C Offline
                      C Offline
                      Chris Berger
                      wrote on last edited by
                      #16

                      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.

                      1 Reply Last reply
                      0
                      Reply
                      • Reply as topic
                      Log in to reply
                      • Oldest to Newest
                      • Newest to Oldest
                      • Most Votes


                      • Login

                      • Don't have an account? Register

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • World
                      • Users
                      • Groups