0

I am working on an application (in php) that needs some rules to evaluate the labelling of some data. Since these rules might change someday, I decided not to hardcode them, rather handle them as configuration for my application.

The above situation might be specific, so my question goes: What are the common (preferably) best practices in early development stage regarding configurations of application with respect to future maintainability?

Edit: This question, unlike some others on this site, doesn't focus on sensitive information (e.g. connection strings), but rather on a general approach to store configs.

gen
  • 328
  • 2
  • 10
  • 3
    ...recommended reading: **[Why is asking a question on “best practice” a bad thing?](http://meta.stackexchange.com/a/142354/165773)** – gnat May 31 '15 at 19:23
  • thank you for the link (although I absolutely disagree with the accepted answer) – gen Jun 02 '15 at 20:58

2 Answers2

1

I wouldun't put it quite like Mike Nakis did, but he has a point.

In a scripting language like PHP, I would recommend creating a class with the various configuration values hard coded either as read only properties or class constants.

It's a scripting language , there is no difference between pushing configfromdb.php, config.yaml, and config.php, and they are harder to deal with due to the extra layer of indirection.

jmoreno
  • 10,640
  • 1
  • 31
  • 48
0

If you are coding in some scripting language like PHP, then investing any effort to avoid hard-coding is a waste of time.

It is a script! Hard-code away! Hard-code everything!

Scripting code is not "hard" code to begin with.

EDIT: please do not confuse "hard coding vs. configuration files" with "declaring constants vs. reusing literals". This question is about "hard coding vs. configuration files".

Mike Nakis
  • 32,003
  • 7
  • 76
  • 111