When reviewing Suggested Edits on Stack Overflow, I often come across "fixed formatting" suggestions that use
inline code spans to place emphasis on certain keywords, but isn't actual code.
I am having a difficult time with a background task in iOS. The problem I seem to be facing is that iOS is silently terminating the App if my background task runs for too long. What can I do to increase time iOS will wait for my background task to complete?
Gets edited to:
I am having a difficult time with a
iOS. The problem I seem to be facing is that
iOSis silently terminating the App if my
background taskruns for too long. What can I do to increase time
iOSwill wait for my
background taskto complete?
This seems like an invalid use of an inline code span because, well, it isn't code, and it is distracting. There are a lot of examples of these edits being made. Often enough they get approved, which reinforces the behavior.
Is this a valid use of inline code spans? If not, should it be edited and corrected? Should edits suggesting these changes be rejected?
Correct, they should be used for code (and code-like artifacts).
If that's the only change, and it's wrongly applied, reject as "no improvement whatsoever" or "causes harm".
I don't have a problem with filenames, paths, API methods, commands, etc.–those are computery "artifacts" that should be differentiated from expository text. Products, trademarks, etc. aren't.
When emphasis or clarification is needed for non-artifacts we have italics and bold.
I believe that code tags should be used for actual code or code keywords. I would reject or revert such edits.
One exception I make is for file names and paths, as I feel these should be offset, and I suppose the argument could be made that file system commands are code.
Apart from using inline code spans for highlighting actual code, you could use them to avoid text is parsed differently, e.g. to avoid that
<body> is parsed as HTML, and rendered as . (It is not actually rendered because it is stripped out.) That is also true for text that in Markdown would be rendered in a particular way, such as
*example* that without inline code spans would be rendered as example.
In the other cases, inline code spans should not be used to highlight plain words; for that there is already bold, and italic styles, which can be easily obtained using Markdown.
If the suggested edit is limited to that, it should be rejected; if the suggested edit is not just that, it should be improved to remove the inline code spans where it has been inappropriately used.
Even in the case inline code spans would be acceptable for highlighting words, not highlighting those words is also acceptable. The change would be a change of style, equivalent of changing the style using to quote phrases from the American style to the British style, such as in the following sentences.
She said "I am late," and closed the door.
She said "I am late", and closed the door.
As such, the suggested edit should be rejected because would be changing the style from an acceptable one to an acceptable one, without making the text clearer.
Using backticks is just a form of emphasis, and shouldn't be restricted to just code. The problem is where too much emphasis is used as per your example, not that it wasn't code.
For example, on Meta I use them to highlight badge names because we don't have any Markdown yet for Badges.
I've also used them instead of quotes to emphasize a quoted term (not a whole sentence).