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. return value optimization

return value optimization

Scheduled Pinned Locked Moved The Weird and The Wonderful
javascriptalgorithmsperformancequestion
16 Posts 8 Posters 0 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.
  • J Jochen Arndt

    The comment is wrong: It must be 200% ;)

    A Offline
    A Offline
    Ankush Bansal
    wrote on last edited by
    #4

    yes indeed :laugh::rose:

    1 Reply Last reply
    0
    • R Rahul Rajat Singh

      I was reading some of the legacy code that is being used by one of our applications. there are some .js files which are meant to be used by new developments so that we dont have to "reinvent the wheel" (thats what we have been told) I opened the first file and first function and i saw

      function somefucntion()
      {
      .
      .
      .
      if (!flag)
      {
      retVal = false;
      return false;
      }

      retVal = true;
      return true;
      

      }

      What the heck? Is this some kind of javascript return value optimization that I am unaware of because i think i can simply replace these lines with return flag; P.S. even after pointing in out I am not allowed to change is as we are not allowed to change this code as "it might break something" (WT Elephant?)

      B Offline
      B Offline
      BobJanova
      wrote on last edited by
      #5

      It can literally be replaced by 'return retval = flag'. If retval isn't local, changing it to 'return flag' might break something, though it's awful code if that's the case.

      1 Reply Last reply
      0
      • R Rahul Rajat Singh

        I was reading some of the legacy code that is being used by one of our applications. there are some .js files which are meant to be used by new developments so that we dont have to "reinvent the wheel" (thats what we have been told) I opened the first file and first function and i saw

        function somefucntion()
        {
        .
        .
        .
        if (!flag)
        {
        retVal = false;
        return false;
        }

        retVal = true;
        return true;
        

        }

        What the heck? Is this some kind of javascript return value optimization that I am unaware of because i think i can simply replace these lines with return flag; P.S. even after pointing in out I am not allowed to change is as we are not allowed to change this code as "it might break something" (WT Elephant?)

        M Offline
        M Offline
        Mohibur Rashid
        wrote on last edited by
        #6

        but the better code would be if(flag) //skipping creating the ! result return true; return false; [edit] i thought it is better :))))))))))))))))))))))))))))))))))))) [/edit]

        B R 2 Replies Last reply
        0
        • M Mohibur Rashid

          but the better code would be if(flag) //skipping creating the ! result return true; return false; [edit] i thought it is better :))))))))))))))))))))))))))))))))))))) [/edit]

          B Offline
          B Offline
          BobJanova
          wrote on last edited by
          #7

          No, "return flag" is better than this. More words is worse if they add nothing.

          J 1 Reply Last reply
          0
          • M Mohibur Rashid

            but the better code would be if(flag) //skipping creating the ! result return true; return false; [edit] i thought it is better :))))))))))))))))))))))))))))))))))))) [/edit]

            R Offline
            R Offline
            Rahul Rajat Singh
            wrote on last edited by
            #8

            IMHO, return flag; is still better than this.

            M 1 Reply Last reply
            0
            • R Rahul Rajat Singh

              IMHO, return flag; is still better than this.

              M Offline
              M Offline
              Mohibur Rashid
              wrote on last edited by
              #9

              oh fuck, i didnt notice the stupidity :))))) sorry guys

              R 1 Reply Last reply
              0
              • M Mohibur Rashid

                oh fuck, i didnt notice the stupidity :))))) sorry guys

                R Offline
                R Offline
                Rahul Rajat Singh
                wrote on last edited by
                #10

                Its ok. If only this realization would have came to the original developer of this code :-)

                1 Reply Last reply
                0
                • A Ankush Bansal

                  Rahul Rajat Singh wrote:

                  "it might break something" (WT Elephant?)

                  Yes it might break original coder's heart :laugh: I once saw this in production code: :laugh:

                  bool func(bool check)
                  {
                  if(check)
                  {
                  if(check)
                  {
                  //Double check to be 100% sure
                  }
                  }
                  }

                  B Offline
                  B Offline
                  BobJanova
                  wrote on last edited by
                  #11

                  I guess this coder had seen the double check synchronisation pattern, e.g.

                  X getSynchronisedSingleCopyOfX(){
                  if(x == null){
                  lock(this){
                  if(x == null) x = new X();
                  }
                  }
                  return x;
                  }

                  ... (commonly used in singleton instantiation) and didn't understand what the real benefit of the double check in that case was. Or maybe he was just an idiot :-\

                  1 Reply Last reply
                  0
                  • R Rahul Rajat Singh

                    I was reading some of the legacy code that is being used by one of our applications. there are some .js files which are meant to be used by new developments so that we dont have to "reinvent the wheel" (thats what we have been told) I opened the first file and first function and i saw

                    function somefucntion()
                    {
                    .
                    .
                    .
                    if (!flag)
                    {
                    retVal = false;
                    return false;
                    }

                    retVal = true;
                    return true;
                    

                    }

                    What the heck? Is this some kind of javascript return value optimization that I am unaware of because i think i can simply replace these lines with return flag; P.S. even after pointing in out I am not allowed to change is as we are not allowed to change this code as "it might break something" (WT Elephant?)

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

                    Yes, you must not change the sacred elephant code or you will anger the coding spirits. ;) If they fear making changes to the code then they need unit tests to prove that the code still works after changes. Also, if the code is so brittle that it may break after a small improvement then it needs reviewed and replaced with better code.

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

                    1 Reply Last reply
                    0
                    • A Ankush Bansal

                      Rahul Rajat Singh wrote:

                      "it might break something" (WT Elephant?)

                      Yes it might break original coder's heart :laugh: I once saw this in production code: :laugh:

                      bool func(bool check)
                      {
                      if(check)
                      {
                      if(check)
                      {
                      //Double check to be 100% sure
                      }
                      }
                      }

                      V Offline
                      V Offline
                      Vasily Tserekh
                      wrote on last edited by
                      #13

                      haah ai was laughing for about a minute, i remember now i was programming in c++ and i received the following message:"suspicious pointer conversion"

                      1 Reply Last reply
                      0
                      • B BobJanova

                        No, "return flag" is better than this. More words is worse if they add nothing.

                        J Offline
                        J Offline
                        jsc42
                        wrote on last edited by
                        #14

                        Actually,

                        return flag

                        could be wrong. flag could be a non-Boolean value (e.g. 0 or "" or [not so well known so a major gotcha] '\n' which have a Boolean equivalent of false; whereas most other values have a Boolean equivalent of true). So, to return false for ! flag and true for flag, you should use

                        return ! ! flag;

                        . This is a useful trick: the 2nd

                        !

                        converts flag (in this case) to a Boolean and negates it (true -> false and false -> true) then the 1st

                        !

                        negates it back to what its Boolean equivalent was.

                        B 1 Reply Last reply
                        0
                        • J jsc42

                          Actually,

                          return flag

                          could be wrong. flag could be a non-Boolean value (e.g. 0 or "" or [not so well known so a major gotcha] '\n' which have a Boolean equivalent of false; whereas most other values have a Boolean equivalent of true). So, to return false for ! flag and true for flag, you should use

                          return ! ! flag;

                          . This is a useful trick: the 2nd

                          !

                          converts flag (in this case) to a Boolean and negates it (true -> false and false -> true) then the 1st

                          !

                          negates it back to what its Boolean equivalent was.

                          B Offline
                          B Offline
                          BobJanova
                          wrote on last edited by
                          #15

                          Good point, although using a variable name of 'flag' for something which wasn't a boolean would be deserving of headline mention in this forum! Can't you just cast to boolean instead of using !!?

                          J 1 Reply Last reply
                          0
                          • B BobJanova

                            Good point, although using a variable name of 'flag' for something which wasn't a boolean would be deserving of headline mention in this forum! Can't you just cast to boolean instead of using !!?

                            J Offline
                            J Offline
                            jsc42
                            wrote on last edited by
                            #16

                            BobJanova wrote:

                            Can't you just cast to boolean instead of using !!?

                            Yes, you could. Casting could be done using

                            return Boolean(flag);

                            Note that

                            return new Boolean(flag);

                            would return a Boolean object whereas without the new keyword, you'd be casting to a Boolean primitive. Greater clarity could be effected by using the triadic operator:

                            return flag ? true : false;

                            or you could use short circuiting, viz

                            return flag && true;

                            but using ! ! flag is more succinct. (I noticed yesterday a piece of jQuery that used !1 for false - I wouldn't go that far in obfuscation).

                            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