[ 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.