Should I include some sample files in a tests/ directory to demonstrate how the settings upgrade / key renames / default overrides ? They won't be installable at runtime (since we don't want users to accidentally create a profile which will have its key values changed by some testing code), but at least they could be there for example's sake.
> Also another reason why I had boolean parameters:
Though in reality, CCSSetting needs to be an abstracted class or something since this code really just abuses the structure into storing some temporary data.
Should I include some sample files in a tests/ directory to demonstrate how the settings upgrade / key renames / default overrides ? They won't be installable at runtime (since we don't want users to accidentally create a profile which will have its key values changed by some testing code), but at least they could be there for example's sake.
> Also another reason why I had boolean parameters:
> - ccsSetString (setting, value, TRUE);
> + ccsSetString (setting, value, FALSE);
> This tells the reviewer exactly nothing.
Yes, that need to be changed to:
enum
{
WriteSetting,
SetTemporary
};
Though in reality, CCSSetting needs to be an abstracted class or something since this code really just abuses the structure into storing some temporary data.