On 6/19/2014 10:00 PM, Masayuki Nakano wrote:
> I'm looking for guidelines for naming preferences. However, I've never
> found it yet. I guess that there is no guidelines.
That is correct. The current rule is to use common sense and coordinate
with the module owner.
If the pref will be exposed in the UI preferences, you should also
coordinate with UX design to make sure that we can express the
preference in the UI in a useful way.
> When I work on some bugs, I need to add a new option for a pref
> switchable behavior, e.g., if we need to add a new option to a feature
> and the new one isn't enabled in default settings, it's better to add
> new pref for the additional option in some cases.
Here are the reasons we should be adding prefs:
A. We actually want to expose the option in the preference UI (needs UX
review)
B. To enable release drivers to turn it off easily if there is a problem
found
C. a feature is experimental and we want to limit it to certain channels
while it is stabilized
D. To enable other internal usage: e.g. A/B testing via telemetry
experiments
I believe that we should not be adding hidden prefs just because a small
minority of people might want a feature, but we've decided not to expose
it in the browser preferences. Those kinds of choices should be made by
installing Firefox extensions. In particular, using an extension instead
of a hidden pref setting means that we will see the non-default choice
in various metrics like about:support, telemetry/FHR, and that Firefox
safe mode reverts the setting in case of problems.
In any case, this probably doesn't have much to do with naming ;-)
> I think that a pref which enables/disables a feature should end with
> |.enabled|. Then, above example becomes:
>
> > |foo.a_feature_name.enabled|
> > |foo.a_feature_name.disabled_on_some_environments|
If it's a boolean feature, I think the common pattern is to used
foo.feature.enabled. e.g. app.update.enabled or dom.ipc.plugins.enabled.
This sounds reasonable to document.
>
> The can be defined by a formula:
>
> <general-group>.(<sub-group>.)*<target-feature>.<state>
>
> The <state> shouldn't be omitted.
I think this rule is too general. Let's stick with the "enabled" rule
for now.
>
> And also, <sub-group> should be used as far as possible.
Why? Flat names seem quite reasonable.
How expensive? Pref changes at runtime are in quite unusual after
startup, and I don't think we should necessarily optimize for this case.
On the other hand, I do think it makes sense to consider the
implementation when defining a pref namespace: if you're observing an
overly broad branch and there's an easy way to design that away, that
sounds reasonable.
> # Anyway, if it's allowed, we should rename the pref names referred
> from nxXPLookAndFeel even though customized users will need to set
> them again.
Do we need this code at all? This sounds like the kind of code that
would be better to remove entirely.
--BDS