As a general rule of thumb I don't hardcode anything that could be user configurable or is likely to change on a regular basis. All program configuration is stored away in a config file. YMMV on this but this is a policy that is enforced here at work and seems to work out quite well for us to be honest.

In my shop we have a development group and an application support group. The application support group are not programmers but are quite technically savvy and are responsible for program configuration. It's quite nice for them to be able to modify a config file if there are any minor tweaks needed (i.e a different directory, a different URL, maintaining an email distro list etc). That way we don't have to release a new version of the program when one of these minor tweaks is needed.

Config files start making a lot of sense if you have quite a strict ticketing->development->QA->release process like we do here at work. If some of those configuration type items were hardcoded, it might take one or two weeks just to get a new release out.

As I said, YMMV but config files seem to work out rather nicely for my development group.

-- vek --