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. The Lounge
  3. Does not Developers get confused if there are too many global variables?

Does not Developers get confused if there are too many global variables?

Scheduled Pinned Locked Moved The Lounge
architecturequestion
67 Posts 29 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.
  • V Valery Possoz

    I once worked on a project with over 3000 global variables. The "team leader" did not even know what half of them were suppose to be for... He just use to add new ones!! I let you guess the quality of the project! So yes they get confused... :(

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

    That's one big problem, I've seen many projects like this (especially in VB6). The list of globals has a tendency to grow, never to shrink. Cleaning (or even understanding) such programs is an exercise in frustration.

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

    1 Reply Last reply
    0
    • M Mohammed Hameed

      It has been noticed that some developers heavily use Global variables, may be without any discomfort. Is it like they get accustomed to it and hence use it? Dont they get confused by over usage?

      Understand SOLID! Believe SOLID! Try SOLID; your Code becomes Rock SOLID!!!

      S Offline
      S Offline
      StatementTerminator
      wrote on last edited by
      #54

      It's simple really: variables should be visible only where they need to be, which means the scope should be as limited as possible. There are lots of reasons for this, including the fact that some of the worst bugs in the world are caused by using variables with too wide of a scope. I once saw a daily import of very important financial data blow up due to such a bug. The guy who wrote the import routine in T-SQL read the identity of the last inserted record of a certain table using @@IDENTITY. This was important because if it got the wrong identity back foreign keys would get all screwed up during the import. Anyway, guess what happened when another developer innocently added a trigger to the table for bulk imports? Yeah. @@IDENTITY is essentially global in scope, so adding an insert trigger to the table--which should have been fine--blew it the hell up. That ended up costing a good chunk of real money for the company. It was also a hard one to debug, because the trigger was the only new code and everyone looked over it and it looked fine, it took a while to figure out what was happening with the import routine which had been in production for years. And all because @@IDENTITY was used instead of SCOPE_IDENTITY. There are very few cases where global variables are a good idea. They make good time bombs though.

      M 1 Reply Last reply
      0
      • R Rob Grainger

        Actually, public statics are nearly as bad. The crucial factor here is that they can introduce problems in the presence of concurrency - if two tasks/threads/... attempt to update the same global/static, the state of the system becomes indeterminate. Singletons are frequently referred to as an anti-pattern for exactly this reason. All such rules are made to be broken, however, and I sometimes have to use public statics - to avoid passing some variable references absolutely everywhere (because most languages don't have good support for lexical scoping). But I do think about each and every such useful very carefully and prefer to find alternatives.

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

        G Offline
        G Offline
        GenJerDan
        wrote on last edited by
        #55

        Rob Grainger wrote:

        Actually, public statics are nearly as bad. The crucial factor here is that they can introduce problems in the presence of concurrency - if two tasks/threads/... attempt to update the same global/static, the state of the system becomes indeterminate.

        Yeah, I hate it when a program ignores what I've written and starts doing things on its own.

        YouTube and My Mu[sic], Films and Windows Programs, etc.

        1 Reply Last reply
        0
        • M Mohammed Hameed

          It has been noticed that some developers heavily use Global variables, may be without any discomfort. Is it like they get accustomed to it and hence use it? Dont they get confused by over usage?

          Understand SOLID! Believe SOLID! Try SOLID; your Code becomes Rock SOLID!!!

          P Offline
          P Offline
          patbob
          wrote on last edited by
          #56

          I see people use global variables (and class statics, and sometimes singletons) when they don't want to think too hard about how, and where, it will need to be accessed. Confusion? Yeah. Discomfort? Those who use them a lot, get used to keeping track of their scope of use manually.. and once you get into that style of coding, more aren't necessarily much worse. Conveying that scope of use information to the next programmer is difficult, and very quickly the code ends up on a toboggan ride to a very warm place. Unless they're used to hold immutable data that's set up very early in the program, they're usually a maintenance nightmare.

          We can program with only 1's, but if all you've got are zeros, you've got nothing.

          M 1 Reply Last reply
          0
          • M Mohammed Hameed

            It has been noticed that some developers heavily use Global variables, may be without any discomfort. Is it like they get accustomed to it and hence use it? Dont they get confused by over usage?

            Understand SOLID! Believe SOLID! Try SOLID; your Code becomes Rock SOLID!!!

            R Offline
            R Offline
            RafagaX
            wrote on last edited by
            #57

            If your program uses global variables, they tend to grow over time, given that every new person that comes next will introduce their own (often redundant) global variables, not for laziness, but because they don't know whether using and existing one will have any side effects anywhere else in the code base, so please don't use them or at least keep it at minimum.

            CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...

            S M 2 Replies Last reply
            0
            • R RafagaX

              If your program uses global variables, they tend to grow over time, given that every new person that comes next will introduce their own (often redundant) global variables, not for laziness, but because they don't know whether using and existing one will have any side effects anywhere else in the code base, so please don't use them or at least keep it at minimum.

              CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...

              S Offline
              S Offline
              StatementTerminator
              wrote on last edited by
              #58

              RafagaX wrote:

              because they don't know whether using and existing one will have any side effects anywhere else in the code base

              Exactly! Because in order to work with global variables and avoid unwanted side-effects, you have to understand how the variables are used in the entire scope, and since they're global that means the whole enchilada! Imagine what you'd have to do to in order to safely re-factor the code to clean up the existing global variables. So the global variables become a house of cards that no one dares to touch. Adding "special" new ones that look just like old ones but were added by a different dev who didn't know exactly how the old ones were being used...that becomes the safe way to go :wtf:

              1 Reply Last reply
              0
              • M Mohammed Hameed

                Thanks Chris. Yes, that would be the case.

                Understand SOLID! Believe SOLID! Try SOLID; your Code becomes Rock SOLID!!!

                D Offline
                D Offline
                dave wg halsall
                wrote on last edited by
                #59

                I have a project that uses quite a few public statics to hold configuration information. IE. different customers have different features and expect slightly different behaviour from the application. I think this is fairly reasonable as they are set only at the time the application starts up and never change. I'd be interested to know how other people would tackle this.

                M 1 Reply Last reply
                0
                • M Mohammed Hameed

                  It has been noticed that some developers heavily use Global variables, may be without any discomfort. Is it like they get accustomed to it and hence use it? Dont they get confused by over usage?

                  Understand SOLID! Believe SOLID! Try SOLID; your Code becomes Rock SOLID!!!

                  B Offline
                  B Offline
                  BrainiacV
                  wrote on last edited by
                  #60

                  In the olden days all there were, were global variables. You young'uns need to learn how to suck it up and program like a real men. :laugh:

                  Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.

                  1 Reply Last reply
                  0
                  • M Mohammed Hameed

                    It has been noticed that some developers heavily use Global variables, may be without any discomfort. Is it like they get accustomed to it and hence use it? Dont they get confused by over usage?

                    Understand SOLID! Believe SOLID! Try SOLID; your Code becomes Rock SOLID!!!

                    B Offline
                    B Offline
                    BotReject
                    wrote on last edited by
                    #61

                    Depends what you mean by 'too many'. Not everything has to be object-oriented, there is nothing wrong in using non-OO code for a simple script of a few hundred lines, or indeed using semi-OO as might be used in classic C++ for a a few thousand lines. It is not wise to insist on dogma if it means using a bazooka to swat a fly. Indeed, scripts were intended to be kept simple, it is only fairly recent demands to increase the complexity of JS that has resulted in attempts to make it OO. Personally, I think that if code gets this complex then it's better to use server-side C# or something similar, though people are doing some heavy work with JS these days and doing it well. That's my opinion as a humble amateur. One thing I have learnt over the years - for every coding dogma there is at least one exception, almost without exception.

                    M 1 Reply Last reply
                    0
                    • B BotReject

                      Depends what you mean by 'too many'. Not everything has to be object-oriented, there is nothing wrong in using non-OO code for a simple script of a few hundred lines, or indeed using semi-OO as might be used in classic C++ for a a few thousand lines. It is not wise to insist on dogma if it means using a bazooka to swat a fly. Indeed, scripts were intended to be kept simple, it is only fairly recent demands to increase the complexity of JS that has resulted in attempts to make it OO. Personally, I think that if code gets this complex then it's better to use server-side C# or something similar, though people are doing some heavy work with JS these days and doing it well. That's my opinion as a humble amateur. One thing I have learnt over the years - for every coding dogma there is at least one exception, almost without exception.

                      M Offline
                      M Offline
                      Mohammed Hameed
                      wrote on last edited by
                      #62

                      Thanks

                      http://authenticcode.com

                      1 Reply Last reply
                      0
                      • D dave wg halsall

                        I have a project that uses quite a few public statics to hold configuration information. IE. different customers have different features and expect slightly different behaviour from the application. I think this is fairly reasonable as they are set only at the time the application starts up and never change. I'd be interested to know how other people would tackle this.

                        M Offline
                        M Offline
                        Mohammed Hameed
                        wrote on last edited by
                        #63

                        Most of the times I prefer storing name/key pairs in config file rather than using lot of static fields.

                        http://authenticcode.com

                        1 Reply Last reply
                        0
                        • R RafagaX

                          If your program uses global variables, they tend to grow over time, given that every new person that comes next will introduce their own (often redundant) global variables, not for laziness, but because they don't know whether using and existing one will have any side effects anywhere else in the code base, so please don't use them or at least keep it at minimum.

                          CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...

                          M Offline
                          M Offline
                          Mohammed Hameed
                          wrote on last edited by
                          #64

                          Thanks a lot. You have raised a very unique reason to avoid using Global variables as much as possible.

                          http://authenticcode.com

                          1 Reply Last reply
                          0
                          • P patbob

                            I see people use global variables (and class statics, and sometimes singletons) when they don't want to think too hard about how, and where, it will need to be accessed. Confusion? Yeah. Discomfort? Those who use them a lot, get used to keeping track of their scope of use manually.. and once you get into that style of coding, more aren't necessarily much worse. Conveying that scope of use information to the next programmer is difficult, and very quickly the code ends up on a toboggan ride to a very warm place. Unless they're used to hold immutable data that's set up very early in the program, they're usually a maintenance nightmare.

                            We can program with only 1's, but if all you've got are zeros, you've got nothing.

                            M Offline
                            M Offline
                            Mohammed Hameed
                            wrote on last edited by
                            #65

                            Great expalanation. Thank you.

                            http://authenticcode.com

                            1 Reply Last reply
                            0
                            • S StatementTerminator

                              It's simple really: variables should be visible only where they need to be, which means the scope should be as limited as possible. There are lots of reasons for this, including the fact that some of the worst bugs in the world are caused by using variables with too wide of a scope. I once saw a daily import of very important financial data blow up due to such a bug. The guy who wrote the import routine in T-SQL read the identity of the last inserted record of a certain table using @@IDENTITY. This was important because if it got the wrong identity back foreign keys would get all screwed up during the import. Anyway, guess what happened when another developer innocently added a trigger to the table for bulk imports? Yeah. @@IDENTITY is essentially global in scope, so adding an insert trigger to the table--which should have been fine--blew it the hell up. That ended up costing a good chunk of real money for the company. It was also a hard one to debug, because the trigger was the only new code and everyone looked over it and it looked fine, it took a while to figure out what was happening with the import routine which had been in production for years. And all because @@IDENTITY was used instead of SCOPE_IDENTITY. There are very few cases where global variables are a good idea. They make good time bombs though.

                              M Offline
                              M Offline
                              Mohammed Hameed
                              wrote on last edited by
                              #66

                              Agreed. Thank you.

                              http://authenticcode.com

                              1 Reply Last reply
                              0
                              • L Lost User

                                Not that I am particularly defending the use of var, but I quite like it in the case of

                                var foo = new SomeReallyQuiteSensibleButLongName();

                                especially if there are a few of them (cuz they line up and look nice) You can see what the type is easily, so no harm done. When it is

                                var foo = TheResultOfSomeFunctionWhoseNAmeDoesntReflectItsReturnType();

                                it annoys me as I have to use intellisense to ind out what type it is. Especially annoying with something like

                                var selectedCustomer = GetCustomerFromList();

                                which, at first glance, I would guess at selectedCustomer being some kind of Customer object. Imagine my surprise when I find out it is a boolean! Yep - the function returns a boolean that determines whether the customer was selected from the list. Now this comes down to good naming - and I have yet to meet a developer that names consistently well (myself included)

                                MVVM # - I did it My Way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')

                                M Offline
                                M Offline
                                Mohammed Hameed
                                wrote on last edited by
                                #67

                                Thanks for good explanation.

                                http://authenticcode.com

                                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