Quoting in Documentation
2015-08-28
I just ran across a small niggle in the DateTime::Format::Strptime docs:
%N Nanoseconds. For other sub-second values use %[number]N.
I needed a 3-decimal sub-second value, so I went off and dutifully wrote:
my $formatter = DateTime::Format::Strptime->new(
pattern => q{'%FT%T.%[3]N%z'},
);
Note my simple-stupid copy of the square brackets. This creates dates like:
2015-08-28T13:31:55.%[3]N-0400
Which is not at all what I had in mind. Then I smacked my forehead, remembering printf()
conventions, and wrote:
my $formatter = DateTime::Format::Strptime->new(
pattern => q{'%FT%T.%3N%z'},
);
No square brackets, and everything works fine.
This issue of direct quoting conventions reminds me of an entry on writing style from the Jargon File:
Consider, for example, a sentence in a vi tutorial that looks like this:
Then delete a line from the file by typing “dd”.
Standard usage would make this
Then delete a line from the file by typing “dd.”
but that would be very bad — because the reader would be prone to type the string d-d-dot, and it happens that in vi(1), dot repeats the last command accepted. The net result would be to delete two lines!
This isn’t quite a “standard usage” issue. It’s an American usage issue. British style for quotes sensibly puts the period on the outside, in agreement with the Jargon File above.
The problem with the Strptime method above is that the convention is ad-hoc, hoping that the reader will catch on to the author’s intent. This tends to cause problems for newer programmers, and even more experienced programmers may take a few iterations to catch on. In some cases, it could also confuse programmers with a different social background.
One solution is to lay out a style guideline at the beginning of the documentation. Programming books will often do this. It’s also similar to the way RFC2119 lays out the definitions of “MUST”, “SHOULD”, etc. in a way that’s intended to be used by other RFCs.
The problem here is that you’re expecting your readers to know that much more before getting into the nuts and bolts of your library. Language and protocol definitions need to be specified very precisely, but library documentation doesn’t necessarily require that–clarity of understanding and succinctness can be better than rigor. Plus, there’s bound to be competing systems of style guidelines, and readers will have to know all of them, or at least the more popular ones.
Instead, it’s enough to give a quick example. Consider if the Strptime docs had said something like:
%N Nanoseconds. For other sub-second values use %[number]N. Example: ‘%T.%3N’
And now there is no question on the square brackets being included in the string or not. Everything the reader needs to know is encapsulated in a single location of the docs–no referencing back to other sections or documents.