Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] RE: global variables - was referring to CODE COMPLETE

Expand Messages
  • Peter Hansen
    ... I think that, by definition, globals increase coupling. Now if few things actually use that global, the increase is minimized, but it would definitely be
    Message 1 of 3 , Mar 30, 2002
    • 0 Attachment
      Alan Shalloway wrote:
      >
      > Actually, using global variables isn't necessarily bad. It's using global,
      > non-const variables that cause trouble. Singletons are a kind of global.
      > The problem is when globals increase coupling between things - that's bad.

      I think that, by definition, globals increase coupling. Now if few
      things actually use that global, the increase is minimized, but it
      would definitely be better to eliminate it entirely by not using them.

      It's just that other things can override the goal of minimal coupling.

      > If a global variable can be changed by something, then everything that uses
      > that is coupled to the object that can change the global (bad). I always
      > believe in getting down to first principles:
      > 1) loose coupling
      > 2) strong cohesion
      > 3) no redundancy
      > Most of our rules of coding come from these.

      No argument there, but in the example I gave these things are
      of lesser concern than the tight memory constraint, so globals
      are (grudgingly) acceptable.

      -Peter
    • jeffgrigg63132
      ... Right! Everything has a scope -- local, (class/instance) member, module/file/package, global. Putting things at a higher scope than needed is a bad idea.
      Message 2 of 3 , Mar 31, 2002
      • 0 Attachment
        > Alan Shalloway wrote:
        > > Actually, using global variables isn't necessarily bad. [...]
        > > The problem is when globals increase coupling between things
        > > - that's bad.

        --- Peter Hansen <peter@e...> wrote:
        > [...] globals increase coupling. [...] it
        > would definitely be better to eliminate [the coupling]
        > entirely by not using them.
        >
        > [...] other things can override the goal of minimal coupling.

        Right!

        Everything has a scope -- local, (class/instance) member,
        module/file/package, global.

        Putting things at a higher scope than needed is a bad idea. I often
        fight VB developers who have a habit of putting variables at the
        class member level (form level) that really ought to be local to the
        methods -- like temporary strings for building the current SQL
        statement or error message.

        I often refactor globals into parameters, reducing the coupling in
        large portions of systems. But some data is so static and
        conceptually global, that it's hard to justify bundling and passing
        it as parameters to all the lowest levels of the system. In practice
        I've found that most (non-XP) projects have bigger wolves to kick of
        the doorstep than a few residual globals.

        -- jeff


        "Error 15 - Unable to exit Windows. Try the door."
      • alshalloway
        I think the key word that was missed was necessarily . I agree, much/most of the time globals are used they increase coupling that is not inherent in the
        Message 3 of 3 , Mar 31, 2002
        • 0 Attachment
          I think the key word that was missed was "necessarily". I agree,
          much/most of the time globals are used they increase coupling that is
          not inherent in the problem domain. However, to say never to use
          globals is the same as saying don't use static (class)
          members/methods.

          I think "avoid globals" is a good rule of thumb, but do not believe
          it is a general principle. For example, driving on the right side of
          the road is a good rule of thumb. However, it doesn't work very well
          in England, nor in the US on one-way roads if you want to make a left-
          hand turn (although this _does_ happen a lot in Boston ;)

          I guess what I am trying to say is that it is important to get very
          good at core principles: loose coupling, strong cohesion, no
          redundancy. Rules of thumb can give us suggested ways to achieve
          these - but they will also often conflict with each other.

          This is particularly important in XP because quality code is very
          important in order to be able to achieve emergent design through
          refactoring.

          I think of classes/objects as sets of responsibilities (not data with
          methods - although accurate, leads to trouble). The question of
          whether to use a class method or member relates to how many places in
          the system have a particular responsibility. If the problem domain
          dictates that only one place have a particular responsibility (all of
          the time) then a static (global) member/method may be applicable (and
          maybe not).

          Alan Shalloway


          --- In extremeprogramming@y..., "jeffgrigg63132" <jgrigg@m...> wrote:
          > > Alan Shalloway wrote:
          > > > Actually, using global variables isn't necessarily bad. [...]
          > > > The problem is when globals increase coupling between things
          > > > - that's bad.
          >
          > --- Peter Hansen <peter@e...> wrote:
          > > [...] globals increase coupling. [...] it
          > > would definitely be better to eliminate [the coupling]
          > > entirely by not using them.
          > >
          > > [...] other things can override the goal of minimal coupling.
          >
          > Right!
          >
          > Everything has a scope -- local, (class/instance) member,
          > module/file/package, global.
          >
          > Putting things at a higher scope than needed is a bad idea. I
          often
          > fight VB developers who have a habit of putting variables at the
          > class member level (form level) that really ought to be local to
          the
          > methods -- like temporary strings for building the current SQL
          > statement or error message.
          >
          > I often refactor globals into parameters, reducing the coupling in
          > large portions of systems. But some data is so static and
          > conceptually global, that it's hard to justify bundling and passing
          > it as parameters to all the lowest levels of the system. In
          practice
          > I've found that most (non-XP) projects have bigger wolves to kick
          of
          > the doorstep than a few residual globals.
          >
          > -- jeff
          >
          >
          > "Error 15 - Unable to exit Windows. Try the door."
        Your message has been successfully submitted and would be delivered to recipients shortly.