[ Content | View menu ]

Static Cling

Mark Mzyk | February 19, 2008

While my experience programming is by my own admission limited, I’ve somehow never questioned the use of static state.

Room 101: Cutting out Static made me for the first time question the use of static state.

I’d never considered the implications of having static state scattered around my programs.  Of course, I haven’t worked on programs or applications I would consider overly complicated either.

A brief highlight of what static state is bad for, according to Room 101:

  • Security
  • Distribution
  • Concurrency
  • Re-entrancy
  • Memory management
  • Start up time

The post expounds further on why each of these is bad*.  Security and concurrency leapt out to me.  In the world of the web those are becoming ever more important.  I think start up time will also be an issue.  If you can’t start an instance of your program quickly, then how are you supposed to take advantage of innovations such as cloud computing?

Why have I used static state in the past?  To me, it seemed to offer a sense of tighter, more well written code.  I felt I could avoid repetition with it.  I’d never stopped to think how it made it harder to alter my programs by more tightly coupling them.  Now it just seems like I used static state because I was being uncreative.

Next time I’ll think a bit more before I include static state.  It might be a good habit to break now, before it becomes a necessity to break it in the future.

*Be sure to read the comments of the post too, as several excellent questions are raised and answered.

Filed in: General,Languages.

3 Comments

  1. Comment by Kevin Smith:

    Static state is so bad that I refuse to use it 9 times out of 10. I have scars from dealing with at least 3 of the six reasons listed (concurrency, re-entrancy, memory management for those who care).

    February 19, 2008 @ 22:23
  2. Comment by Tom R:

    Static Variables have real uses in multi-threaded applications where shared memory is needed to relay information. Like many things in Computer Science, tools such as static can be abused – but only because the developer who leveraged the technology didn’t know what they were doing.

    If you develop static/shared memory code with either “write once, ready many” or mutex/semaphores in mind – its fairly safe and easy to manage.

    February 19, 2008 @ 23:01
  3. Comment by Mark:

    Tom –

    With the likes of Erlang and other functional languages, static state isn’t even an issue since it doesn’t exist and the programmer therefore doesn’t even have to think about constructs such as share memory and semaphores.

    While on a small level it can be easy to manage share state, as applications scale bugs in shared state can become incredibly difficult to deal with it, and I think it is an area many programmers are weak in.

    I think there are two options to deal with this: either eliminate shared state, or else do a much better job teaching how to manage shared state than is currently done. Option one seems like the much easier option to achieve.

    February 20, 2008 @ 22:19