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. Switch boolean.... (reinventing if, unnecessarily)

Switch boolean.... (reinventing if, unnecessarily)

Scheduled Pinned Locked Moved The Weird and The Wonderful
47 Posts 32 Posters 6 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.
  • R Rob Grainger

    Came across this kind of code today...

    void EnableFromValue(bool enabled)
    {
    switch (enabled) {
    case true:
    FirstControl.Enabled = true;
    SecondControl.Enabled = true;
    ...
    break;
    case false:
    FirstControl.Enabled = false;
    SecondControl.Enabled = false;
    ...
    break;
    }
    }

    I'm sure there must be a better way ;-)

    "If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.

    J Offline
    J Offline
    Jeremy Falcon
    wrote on last edited by
    #2

    I voted this a 5 because it was funny, but I could see a valid reason for that... if they wanted to encapsulate the logic of which controls were affected into a single resource I could see me doing that. Especially if it's called in more than one area.

    Jeremy Falcon

    F 1 Reply Last reply
    0
    • R Rob Grainger

      Came across this kind of code today...

      void EnableFromValue(bool enabled)
      {
      switch (enabled) {
      case true:
      FirstControl.Enabled = true;
      SecondControl.Enabled = true;
      ...
      break;
      case false:
      FirstControl.Enabled = false;
      SecondControl.Enabled = false;
      ...
      break;
      }
      }

      I'm sure there must be a better way ;-)

      "If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.

      Z Offline
      Z Offline
      ZurdoDev
      wrote on last edited by
      #3

      This happens to me sometimes, until I get a few lines into and realize that there is a much simpler way. :doh:

      There are only 10 types of people in the world, those who understand binary and those who don't.

      1 Reply Last reply
      0
      • R Rob Grainger

        Came across this kind of code today...

        void EnableFromValue(bool enabled)
        {
        switch (enabled) {
        case true:
        FirstControl.Enabled = true;
        SecondControl.Enabled = true;
        ...
        break;
        case false:
        FirstControl.Enabled = false;
        SecondControl.Enabled = false;
        ...
        break;
        }
        }

        I'm sure there must be a better way ;-)

        "If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.

        S Offline
        S Offline
        Silvabolt
        wrote on last edited by
        #4

        So better way is this?

        FirstControl.Enabled = enabled;
        SecondControl.Enabled = enabled;

        or better yet, MVVM would help if applicable to the app.

        R B C 3 Replies Last reply
        0
        • S Silvabolt

          So better way is this?

          FirstControl.Enabled = enabled;
          SecondControl.Enabled = enabled;

          or better yet, MVVM would help if applicable to the app.

          R Offline
          R Offline
          Rob Grainger
          wrote on last edited by
          #5

          That's the gist of it yep. This is in an MVVM app, using a framework I architected. Sadly, one of the dev's has a habit of naming View Model fields too literally after the thing in the View, so it still ends up looking like code manipulating the view directly (and at the other extreme, a hell of a lot of business logic has polluted the view model). So, while the controls may not be called "FirstControl" etc., its really not that far off - properties with names like "CustomerListBoxSelectedCustomer". I try to clear up as much as I can as I work with stuff, but it seems some people just don't want to learn to work with architecture.

          "If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.

          D K 2 Replies Last reply
          0
          • R Rob Grainger

            Came across this kind of code today...

            void EnableFromValue(bool enabled)
            {
            switch (enabled) {
            case true:
            FirstControl.Enabled = true;
            SecondControl.Enabled = true;
            ...
            break;
            case false:
            FirstControl.Enabled = false;
            SecondControl.Enabled = false;
            ...
            break;
            }
            }

            I'm sure there must be a better way ;-)

            "If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.

            P Offline
            P Offline
            phil o
            wrote on last edited by
            #6

            At least, his casing is ok.

            while (true) {
            continue;
            }

            1 Reply Last reply
            0
            • R Rob Grainger

              Came across this kind of code today...

              void EnableFromValue(bool enabled)
              {
              switch (enabled) {
              case true:
              FirstControl.Enabled = true;
              SecondControl.Enabled = true;
              ...
              break;
              case false:
              FirstControl.Enabled = false;
              SecondControl.Enabled = false;
              ...
              break;
              }
              }

              I'm sure there must be a better way ;-)

              "If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.

              K Offline
              K Offline
              kmoorevs
              wrote on last edited by
              #7

              Thanks for posting! After two weeks without a new thread, I was starting to think that we are all working on perfect code! BTW, the example is perfect for getting your LOC up! :laugh:

              "Go forth into the source" - Neal Morse

              1 Reply Last reply
              0
              • R Rob Grainger

                That's the gist of it yep. This is in an MVVM app, using a framework I architected. Sadly, one of the dev's has a habit of naming View Model fields too literally after the thing in the View, so it still ends up looking like code manipulating the view directly (and at the other extreme, a hell of a lot of business logic has polluted the view model). So, while the controls may not be called "FirstControl" etc., its really not that far off - properties with names like "CustomerListBoxSelectedCustomer". I try to clear up as much as I can as I work with stuff, but it seems some people just don't want to learn to work with architecture.

                "If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.

                D Offline
                D Offline
                DJ van Wyk
                wrote on last edited by
                #8

                Someone needs to sit down with the guy and give him some 'help' to understand decent coding practices. Keep a hammer ready ...

                My plan is to live forever ... so far so good

                1 Reply Last reply
                0
                • R Rob Grainger

                  Came across this kind of code today...

                  void EnableFromValue(bool enabled)
                  {
                  switch (enabled) {
                  case true:
                  FirstControl.Enabled = true;
                  SecondControl.Enabled = true;
                  ...
                  break;
                  case false:
                  FirstControl.Enabled = false;
                  SecondControl.Enabled = false;
                  ...
                  break;
                  }
                  }

                  I'm sure there must be a better way ;-)

                  "If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.

                  Sander RosselS Offline
                  Sander RosselS Offline
                  Sander Rossel
                  wrote on last edited by
                  #9

                  You aren't working with my previous employer, are you? :laugh:

                  Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.

                  Simplicity is prerequisite for reliability. — Edsger W. Dijkstra

                  Regards, Sander

                  1 Reply Last reply
                  0
                  • J Jeremy Falcon

                    I voted this a 5 because it was funny, but I could see a valid reason for that... if they wanted to encapsulate the logic of which controls were affected into a single resource I could see me doing that. Especially if it's called in more than one area.

                    Jeremy Falcon

                    F Offline
                    F Offline
                    Freak30
                    wrote on last edited by
                    #10

                    I see a reason for the function but not for the switch statement. Except if you are paid by lines of code of course. :-D

                    The good thing about pessimism is, that you are always either right or pleasently surprised.

                    J B D 3 Replies Last reply
                    0
                    • R Rob Grainger

                      Came across this kind of code today...

                      void EnableFromValue(bool enabled)
                      {
                      switch (enabled) {
                      case true:
                      FirstControl.Enabled = true;
                      SecondControl.Enabled = true;
                      ...
                      break;
                      case false:
                      FirstControl.Enabled = false;
                      SecondControl.Enabled = false;
                      ...
                      break;
                      }
                      }

                      I'm sure there must be a better way ;-)

                      "If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.

                      S Offline
                      S Offline
                      Simon ORiordan from UK
                      wrote on last edited by
                      #11

                      The advantage of a switch is that it bails as soon as a test passes, thus reducing conditional branching. Here you could use an if else.

                      S L S 3 Replies Last reply
                      0
                      • S Simon ORiordan from UK

                        The advantage of a switch is that it bails as soon as a test passes, thus reducing conditional branching. Here you could use an if else.

                        S Offline
                        S Offline
                        ScottM1
                        wrote on last edited by
                        #12

                        Or take it out altogether as it's setting 2 Booleans.

                        1 Reply Last reply
                        0
                        • S Simon ORiordan from UK

                          The advantage of a switch is that it bails as soon as a test passes, thus reducing conditional branching. Here you could use an if else.

                          L Offline
                          L Offline
                          Lost User
                          wrote on last edited by
                          #13

                          In that case it has the same advantage as the "if" would have; but if that is an important 'optimization', then you already have a bigger problem :)

                          Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)

                          S 1 Reply Last reply
                          0
                          • R Rob Grainger

                            Came across this kind of code today...

                            void EnableFromValue(bool enabled)
                            {
                            switch (enabled) {
                            case true:
                            FirstControl.Enabled = true;
                            SecondControl.Enabled = true;
                            ...
                            break;
                            case false:
                            FirstControl.Enabled = false;
                            SecondControl.Enabled = false;
                            ...
                            break;
                            }
                            }

                            I'm sure there must be a better way ;-)

                            "If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.

                            M Offline
                            M Offline
                            mbb01
                            wrote on last edited by
                            #14

                            The only reason I could think for writing or keeping the code this way would be if enabled became an enumerated type and had more than 2 states.

                            D 1 Reply Last reply
                            0
                            • L Lost User

                              In that case it has the same advantage as the "if" would have; but if that is an important 'optimization', then you already have a bigger problem :)

                              Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)

                              S Offline
                              S Offline
                              Simon ORiordan from UK
                              wrote on last edited by
                              #15

                              In my experience Microsoft is pretty much immune to optimisation. You can reduce branching by one or two orders of magnitude and the crappy performance just doesn't budge. :zzz:

                              L 1 Reply Last reply
                              0
                              • M mbb01

                                The only reason I could think for writing or keeping the code this way would be if enabled became an enumerated type and had more than 2 states.

                                D Offline
                                D Offline
                                Daniel Pfeffer
                                wrote on last edited by
                                #16

                                In that case - create it as an enumerated type, with two values. You may then expand the enumeration without rewriting the existing code.

                                If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill

                                1 Reply Last reply
                                0
                                • S Simon ORiordan from UK

                                  In my experience Microsoft is pretty much immune to optimisation. You can reduce branching by one or two orders of magnitude and the crappy performance just doesn't budge. :zzz:

                                  L Offline
                                  L Offline
                                  Lost User
                                  wrote on last edited by
                                  #17

                                  Probably because it is a micro-optimization; you won't notice much difference if it merely saves you the toggeling of a boolean.

                                  Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)

                                  S 1 Reply Last reply
                                  0
                                  • L Lost User

                                    Probably because it is a micro-optimization; you won't notice much difference if it merely saves you the toggeling of a boolean.

                                    Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)

                                    S Offline
                                    S Offline
                                    Simon ORiordan from UK
                                    wrote on last edited by
                                    #18

                                    Ha! It was actually an image processing filter mask which used pointer arithmetic. I invented something I called a Summation Threshold Filter which should have been ten times quicker than a Median filter. Let's just say that this was not apparent. :laugh:

                                    1 Reply Last reply
                                    0
                                    • S Simon ORiordan from UK

                                      The advantage of a switch is that it bails as soon as a test passes, thus reducing conditional branching. Here you could use an if else.

                                      S Offline
                                      S Offline
                                      Scott Corbett
                                      wrote on last edited by
                                      #19

                                      Umm...that's not true. A switch will continue to fall through until you get to a break statement or the end of the switch (i.e. the default case.) On the other hand, if/else statements do bail as soon as the first passing conditional is found and the associated code block is executed.

                                      Scott E. Corbett

                                      Richard DeemingR T S 3 Replies Last reply
                                      0
                                      • R Rob Grainger

                                        Came across this kind of code today...

                                        void EnableFromValue(bool enabled)
                                        {
                                        switch (enabled) {
                                        case true:
                                        FirstControl.Enabled = true;
                                        SecondControl.Enabled = true;
                                        ...
                                        break;
                                        case false:
                                        FirstControl.Enabled = false;
                                        SecondControl.Enabled = false;
                                        ...
                                        break;
                                        }
                                        }

                                        I'm sure there must be a better way ;-)

                                        "If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.

                                        M Offline
                                        M Offline
                                        Member 9908362
                                        wrote on last edited by
                                        #20

                                        FirstControl.Enabled = !FirstControl.Enabled;
                                        SecondControl.Enabled = !SecondControl.Enabled;

                                        1 Reply Last reply
                                        0
                                        • R Rob Grainger

                                          That's the gist of it yep. This is in an MVVM app, using a framework I architected. Sadly, one of the dev's has a habit of naming View Model fields too literally after the thing in the View, so it still ends up looking like code manipulating the view directly (and at the other extreme, a hell of a lot of business logic has polluted the view model). So, while the controls may not be called "FirstControl" etc., its really not that far off - properties with names like "CustomerListBoxSelectedCustomer". I try to clear up as much as I can as I work with stuff, but it seems some people just don't want to learn to work with architecture.

                                          "If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.

                                          K Offline
                                          K Offline
                                          Kirk 10389821
                                          wrote on last edited by
                                          #21

                                          Code Reviews Code Reviews Code Reviews Here is a great rule. When someone gets multiple "mandatory" changes needing to be made as a result of a Code Review. Then you must review weekly, ALL of their code. This continues until they no longer require "mandatory" changes for a few weeks in a row. The goals are: 1) Slow them down 2) Get them to proactively ask people how they should code/name something 3) Show them the right way (for your group) to do things Our Code Reviews have 3 Comment Levels: - Mandatory: We will not let this stand in production, must be rewritten - Suggested: We are not thrilled, but if you can "really" defend it. - Noted: We are just making a note, take it or leave it (Variable names, Variable comments) Make Code Reviews fun. Friday starting at lunch time with pizza brought in. It helps you to detach from the depth of coding for the weekend. Besides, Code Reviews are how Good Developers help new Developers!

                                          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