Ban contractions in code documentation

The official style guidelines do not mention contractions. So this issue is a policy discussion.

All documentation and comments should form proper sentences, use proper grammar and punctuation, and generally follow the same style guidelines as Drupal.org content: http://drupal.org/style-guide/content

From https://www.drupal.org/coding-standards/docs#drupal

So it may be more of a suggestion of a formal writing style in the code documentation. A title adjustment should do it. If you can think of a better one, please change it.

Maybe "Adopt a formal writing style in code documentation."

This is a coding standards discussion, so moving to TWG project.

Re: #5, I think this issue should be about a prose standard for code comments.

Re: #5, I think this issue should be about a prose standard for code comments.

Moving this issue to the Coding Standards queue per the new workflow defined in #2428153: Create and document a process for updating coding standards.

Added a suggestion to avoid the use of contractions.

I am not sure if the categorical avoidance of contractions is the right choice here. First a few additional aspects:

1. The Drupal User Interface Standards for interface text have already the requirement not to use contractions (https://www.drupal.org/docs/develop/user-interface-standards/interface-text see the last point within the style section)
2. The Yahoo style guide (Barr 2010: The Yahoo Style Guide) has the recommendation to use contractions with caution. From their point of view readers should know common contractions like it's or she's and some might even understand irregular contractions like let's (let us). While negative contraction, even the simple ones like can't and don't, can easily be misread by people who are only briefly scanning a text. Their recommendation is, for the sake of clarity, in case the information is in particular important, to spell these out (for example, Do not click Buy before you complete the form). While slangy, outdated, or less usual contractions such as ain't, that'll, could've, shan't, 'tis, and the unwieldy shouldn't've should be avoided in general.
3. Erika Jorgensen takes a similar approach in her book on Strategic Content Design. In the section about plain language she actually advocates for the use of contractions. According to her avoiding contractions is another writing rule that was advocated for long ago by English teachers everywhere. From her perspective this recommendation feels extremely outdated, in particular in the context of digital content. Contractions improve the readability and create a more conversational, friendlier tone for your content. According to her there are only a few reasons to avoid contractions. First, cases where one is writing an amicus briefs or some kind of formal legal documents. Second, cases where one is writing a warning or error message in the context of UX content/micro copy. In these cases it can be considered helpful to avoid contraction entirely, because doing so forces the recipient/reader to slow down a bit and to focus on why the error happened and what the exact next steps are they have to take. The example she provided alongside was: The app did not launch can be more emphatic and clearer than The app didn’t launch. In this particular case, not is the most important word in the sentence and you are doing the reader a favor by writing out did not instead of condensing it into didn’t.

The three links about contractions and plain english in the issue summary are in the same vein like point 2 and 3.
So as I've state in my initial statement, I would be rather hesitant to ban and remove contractions from the documentation entirely. I would try to still allow the usage of contractions but avoid negative contractions and maybe conditional contractions. And as a rule of thumb in situations where you as the writer want to be empathic and extra clear avoid contractions as well (see point 3). That would be sort of the middle ground between completely banning contractions or using contractions for everything. From my perspective it would improve the general readability but at the same time the copy would become more clear in the situations where it is necessary. And on a side note, personally I also disagree for the given reasons with the strict ban of contractions in the Drupal User Interface Guidelines in point 1.

General consensus is not to do this, we have had another month of time to see other opinions. Will close this as won't fix.