Should I Protect function's options

Question

I'm trying to figure out what is the best way to protect symbols within a package (a function's options in particular) so that no other value can be assigned to it.

Consider a function myFunc:

Options[myFunc, OptionsPattern[]] = {op1->5}
myFunc[x_] :=
  Module[{},
    (* Function's core implementation *)
    Print[OptionValue[op1]+2];
  ]

If I leave it as is, op1 is unprotected and anyone can assign a value to it. That doesn't seem to affect myFunc's functionality, but seems perhaps unprofessional (?).

Checking the symbol PlotRange, for instance, turns out protected, as it is an option for Plot[] and ListPlot[].

Up until now I've been protecting my options with (right before myFunc's definition):

Unprotect[op1]; 
op1 = op1;
Protect[op1];

I must've seen that somewhere, because I don't remember coming up with it. Apart from the self definition op1=op1, I understand it, but I'm curious to what the "correct" way to do it would be. And also, do I even need to protect it? Or is it just for clarity for the user (and other package makers), saying "Hey, this symbol is an option! Don't get it confused with your variables.".

EDIT: I forgot to mention. I'm also writing documentation for this application, in Wolfram Workbench. So, it's useful to have well defined protected symbols in general that I can document.

Answer 1

Protect everything from the package's context, unless it is explicitly meant to be set by the package's users*. It doesn't matter if the symbol is an option or not.

BeginPackage["Foo`"];

Unprotect["Foo`*"];

(* list all symbols meant for export,
   including any symbols used as options only *)

Begin["`Private`"];

(* package code *)

With[{syms = Names["Foo`*"]},
  SetAttributes[syms, {Protected, ReadProtected}]
];    

End[];

EndPackage[];

I agree with @Henrik that it is good practice to use strings for option names to limit name pollution (and reduce the chance of name conflicts), especially if the option will be used with a single function only.

It is true that if you use the Workbench documentation tools, then it will not be possible to have a separate documentation page for a string option. But should you have one? I prefer to document options in the doc page of the function they belong to—except when the same option is used by several functions with the very same meaning.

---

^{* Even then it's probably better to have the settable symbol protected and overload Set for it—that way you can have error checking for its value.}

Answer 2

I always use strings as the names for the options (like "op1" instead of op1). You cannot overwrite a string. That's good! For some weird reason, you can still use the "unstringfied" version op1 as in myFunc[bla,op1->2]. Of course, myFunc[bla,"op1"->2] is also valid. So, you get safety even without Protection and still you are not forced to type many quotes.