9

I don't agree that storing settings in a database table is a bad separation of concerns. Your "concerns" will be separated by not defining a relationship between the settings table and other tables in your database. This is fine. The main thing to consider is how you expect the administrator of your system to make changes to the settings. It's much easier ...


6

Matt's answer gives good advice (as well as Robert Harvey's comments to the question), but both are IMHO incomplete in regards to the question on how to get up to 50 people on board. The organizational issues for trying to get 5 persons working on the same standard are quite different from the issues you face when you have 50 people to manage. About 20 ...


6

Use one or more published coding standards documents as a starting point for discussion. Many large organizations have made their standards documents freely available on the web for just about every conceivable language and framework. Download some of those documents and distribute them for the team to review and consider, making it clear that the documents ...


4

The largish legacy application I maintain has gone back and forth on this over the years, but has evolved towards keeping most settings in the DB. Yes, the DB connection string is read from the config file. This is a desktop application that heavily uses a DB and which has quite a few settings. If you have very few this will be less applicable, but these are ...


3

It's the lack of style guides. On Mac systems you have Preferences fixed to store your options and settings. Other systems prefer whatever the programmer's taste is to name preferences.


2

Conflicts arise when people's abmitions clash. You can avoid this by using automated system which enforces conventions. Policy documents and coding guides are of little help because they are subject to interpretation. Commit hook checking formatting rules, naming conventions etc is much cleaner solution which ensures everybody gets similar treatment.


2

If you're using NSDefaults (or CFPreferences), you can update the default settings immediately. They get pushed to the background process cfprefsd (short for Core Foundation PREFerenceS Daemon) which holds them in RAM and writes to disk at its leisure. Killing your app does not kill cfprefsd, so the settings don't get lost. (Killing cfprefsd, which I've ...


2

I think it depends on the nature of the settings. Some settings are basically numbers, like number of results to display or a zoom factor or such like. These settings can be read from your settings structure (or API) as needed and plugged in as parameters to functions in your code. I think these are straightforward. Other settings control functionality, ...


Only top voted, non community-wiki answers of a minimum length are eligible