I see this pattern over and over again in PHP applications.

I myself was guilty of it in the past because it does indeed have some attractive reasons for its use.

  1. Your configuration variables' scope is application wide; access it from anywhere</li>
  2. You don't have to be concerned about things stepping on your variables</li>
    </ol>
    It has been my experience though that in terms of this method of doing things, the cons outweigh the pros. In my opinion, you're doing it wrong.

    Most of my reasons for why I think this pattern is wrong revolve around three things

    1. Upgrades</li>
    2. Local configuration</li>
    3. Cross-language config files</li>
      </ol>
      Upgrades</strong>

      Why do constants make for headache? Because you can't stomp on their values during an upgrade. Instead, you need to write out new values and have new constant names.

      Local configuration</strong>

      This is what I consider a Good Idea; local customizations to default config files. Unfortunately, when you have your configuration data stored in constants, you can't step on your default values. This Good Idea loops back up into the Upgrades point above. It is a good idea to ship your apps with a default config file and override values in that default with a local config file. This allows you to upgrade your app without caring about the end-users customizations. Stomp away on that default config file.

      When you have constants though, you can't do this without some over-engineering of your app.

      Cross-language config files</strong>

      Storing your configuration in PHP constants requires that your configuration be stored in PHP code itself.

      This is a really bad idea if there's any chance that your app may want to utilize any other language in itself. If it does, then you need to be able to parse PHP source code just to load your configuration data. It's a far better idea to store your configuration values in something that is easily parsed in many languages; for instance, INI files or XML. Using constants, again, requires over-engineering a solution that is accomplished far easier using just a different file format.

      I wouldn't harp on these practices if I hadn't had first hand experience in their shortcomings. I've made the mistake of using constants for my configuration in the past, but through time and experience have learned better ways to do it.