On 03/14/2017 02:53 PM, Richard Kenner wrote:
The GCC manual uses "cannot" in most places (280 lines) but there
are a few instances of "can't" (33 lines).
The attached patch replaces the informal "can't" with the former
for consistency.
In my opinion, this is the wrong direction. Contractions are becoming
more acceptable in even more formal writing and there's even a current
US Supreme Court justice who uses them in her opinions.
I certainly don't think it's worth a change to use "can't" throughout,
but I'm not in favor of eliminating it either.
I don't consider this change important enough to spend too much
time on but since you voiced an objection but offered little in
the way of a rationale I feel I'd be remiss not to respond and
explain my perspective.
First, I agree that the less formal language is becoming more
acceptable. Some style guides explicitly allow contractions,
but others advise against them. The technical specifications
that significant parts of GCC aim to conform to, and those I
happen to work with the most closely (the C, C++, and POSIX
standards), avoid them. The IEEE Editorial Style Manual
recommends against using them. The author of Engineer's Guide
to Technical Writing, Kenneth Budinski, equates them with slang.
I personally don't feel too strongly about it, but the change
seems like an opportunity to improve not just the style of
the manual but also increase its consistency. I could see
one being indifferent to such changes but I have trouble
understanding how they could be viewed as the wrong direction.
What is your rationale against it and what would you consider
the right direction for the manual?
Martin
PS While researching this subject I came across the following
two interesting references that I think are worth quoting:
In Engineer's Guide to Technical Writing, the author writes:
Contractions should never be used in technical writing [my
opinion]. They are essentially a form of slang, and slang
expressions are not appropriate in technical writing. Some
technical writers disagree with it. They believe that writing
without contractions is stiff. Use the appropriate practice
for your organization. Use contractions sparingly, if at all.
The NASA Technical Documentation Style Guide offers, in my view,
sound advice:
Contractions (for example, it's for it is or it has; don't for
do not; doesn't for does not; isn't for is not; and won't for
will not) are not forbidden in technical or business writing.
A few well-placed contractions can help your material sound as
if a person wrote it--always a worthy goal. But too many
contractions can make your message sound too casual.
The challenge with following this advice in the GCC manual is
that engineers are rarely good at writing or judging the right
tone of text. Often, contributions are also made by non-native
speakers some of whom may not be able to discern between the of
a contraction that helps achieve the goal and one that works
against it. The one thing most of us do have is an eye and
affinity for consistency, so using one style consistently
throughout the manual seems like a good (and safe) approach.
