132

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.

For example:

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 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?

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?

10
  • 7
    I edit these out if I'm fixing something else with a post. With italics and bold and headings for emphasis and line-breaks etc there isn't really any need to have anything else and it just makes the post more difficult to read. Commented Jun 8, 2012 at 14:00
  • 6
    background task doesn't look like valid code at all. But I think the added clarity of the code spans shou ld not be over looked.
    – user7116
    Commented Jun 8, 2012 at 14:03
  • 4
    Interesting; usually I encounter it the other way around — the poster uses emphasis to indicate code.
    – user164291
    Commented Jun 8, 2012 at 17:12
  • 7
    Who are the people approving these edits? Do the approvers have the same writing style as the editors? Then I wouldn't be surprised. Either way, these edits are invalid and should be rejected outright (and reverted if approved). Commented Jun 10, 2012 at 7:56
  • 4
    I'm also looking at the people who use inline code spans as inline quotes in comments. Commented Jun 10, 2012 at 7:56
  • @BoltClock I don't know where the idea came from in the first place; it seems crappy to me, and many people seem to think it is a good idea. (They do seem concentrated in South Asia, but that might just be due to the time of day I tend to do edit reviews.) Commented Jun 10, 2012 at 19:11
  • 2
    I've been so bothered by this nonsense (people suggesting edits and people approving such suggestions) that I've opened a question: meta.stackexchange.com/questions/137755/… You should follow the links there, though, because my proposal isn't all that great. I guess I was just trying to make a point :) Commented Jun 28, 2012 at 5:05
  • Related: meta.stackexchange.com/questions/141089/… Commented Feb 14, 2013 at 3:12
  • 2
    Related: Please ‘never’ use 𝚖𝚘𝚗𝚘𝚜𝚙𝚊𝚌𝚎𝚍 𝚝𝚎𝚡𝚝 or ˋbackticksˋ for emphasis. That’s what italics are for, amongst other things. And go easy on the bold, too, while you’re at it.
    – tchrist
    Commented Jun 2, 2014 at 16:21
  • 2
    Related: meta.gaming.stackexchange.com/q/7437
    – MTL
    Commented Jan 11, 2015 at 0:56

5 Answers 5

122

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.

13
  • 8
    I agree, but "computery thing" tends to be what causes problems. Is iOS a "computery" thing? Yes. Should it be a code span? No.
    – vcsjones
    Commented Jun 8, 2012 at 15:57
  • 30
    @vcsjones No, it isn't, because it's not something you'd type into a computer as a command, or get back from same. Commented Jun 8, 2012 at 16:26
  • 1
    I agree with this totally, and have been using it as a basis for rejecting edits (or a reason for doing edits myself to undo/change) for a few months. Commented Jun 10, 2012 at 19:06
  • 1
    I agree AFA "used for code (and code-like artifacts)"; but I disagree AFA "[i]f that's the only change", the change still being useful by improving readability IMO; and it still has to meet the 6-character minimum for edits (i.e. at least 3 code or code-like artifacts that weren't backticked). If "it's wrongly-applied", I agree again; that's different - wrong being just that and, hence, not useful.
    – J0e3gan
    Commented Apr 21, 2013 at 14:52
  • @J0e3gan Except that formatting even a few keywords beats the minimum: such edits clog the review queues and are not significant enough to warrant making somebody approve it. IMO that kind of improvement should stay in the purview of those that no longer require their edits to be approved. Note that I used the logical operator "and" in that sentence, and I meant to do so. Commented Apr 21, 2013 at 14:53
  • @vcsjones raises a good point; and Dave Newton's follow-on comment is good; but the ambiguity comes from computery "artifiacts" in the answer. The term code-like artifacts used at the outset of the answer is clearer I think.
    – J0e3gan
    Commented Apr 21, 2013 at 14:59
  • 2
    @J0e3gan I see no ambiguity: iOS is a product, and clearly differentiated from the other computery artifacts I list. Quibbling over this is not helpful; but have at it. Commented Apr 21, 2013 at 15:04
  • 7
    Why reject as trivial? Wouldn't rejecting with a custom message linking to this question and answer be far more useful? E.g. Inline code spans should not be used for emphasis. See http://meta.stackexchange.com/questions/135112/inline-code-spans-should-not-be-used-for-emphasis-right
    – Mark Amery
    Commented Jul 28, 2013 at 16:56
  • 4
    @MarkAmery Because (a) only so many hours in a day, and (b) this answer didn't exist as a de facto response until after I wrote it and people voted it up. Commented Jul 28, 2013 at 19:44
  • I see so many edits doing this it nearly should be a preset answer, bad use of backticks
    – mcfedr
    Commented Feb 29, 2016 at 9:42
  • Since I am guilty of using backticks for emphasis (plus, never had an edit rejected because of doing so, so I really thought this was the right way of using it), I ask for clarification: highlighting System.Reflection would be ok, since it's a .NET namespace, but highlighting WinForms wouldn't, because it's the name of a specific toolkit?
    – waka
    Commented Sep 15, 2017 at 15:13
  • 3
    @waka ¯(°_o)/¯ I probably wouldn't use backticks for WinForms, but I would for System.Windows.Forms. I mean, if you're using emphasis in prose you don't monospace it, you bold or italicize, right? Commented Sep 15, 2017 at 17:22
  • 1
    @DaveNewton: Yes, now that you mention it, it does make sense. I don't know where I picked up this habit, but I will make sure to do it right from now on. :)
    – waka
    Commented Sep 15, 2017 at 18:45
27

From the comment by @SevenSidedDie, which deserves to be in its own answer, rather than buried in a comment under a heavily downvoted answer:

[Using backticks is] not just distracting, it's semantically wrong. Code formatting is semantic HTML to indicate to a parser that text is code. If we start lying to our parsers, we break tools built on HTML. Consider screen readers: if a visually impaired user configures their software to spell out code tags, or to have an easy keyboard shortcut with a macro called "jump to next code span/block and highlight" for easy copy-pasting, we are significantly disabling their ability to interact with the page. Further disabling, I should say.

26

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.

13

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.

1
  • 14
    (Although I'd add that <body> would be a code-like artifact already, thus it's appropriate, and *italics* can be escaped with a backslash.) Commented Feb 1, 2013 at 0:24
-45

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).

11
  • 23
    bold and italics are just enough, no need for third form of emphasis. Commented Jan 31, 2013 at 15:06
  • 8
    using for badge names doesn't seem 'wrong' to me but it's worth spelling out that backticks aren't just a form of emphasis—they have the unique feature of making the text monospaced (which of course is what makes them ideal for code). This change of spacing is just distracting (to my eyes at least) when it occurs in the middle of a sentence like the examples given. Commented Jan 31, 2013 at 15:39
  • @JackDouglas, yes, I agree it's a little distracting, but isn't that what emphasis does, distract. I definitely don't like seeing it abused. Commented Jan 31, 2013 at 15:41
  • 2
    To me, "too much" equals "greater than zero" here. Even if only "iOS" was put into backticks in the example above, then that would have bothered me. (Especially so for suggested edits.)
    – Arjan
    Commented Jan 31, 2013 at 17:43
  • 1
    @Arjan, yeh, I don't see the need for any highlighting in that excerpt. Commented Jan 31, 2013 at 17:45
  • 1
    I think I'd use <kbd> for badges, although I've never actually tried it. Commented Feb 1, 2013 at 0:26
  • 27
    @LanceRoberts It's not just distracting, it's semantically wrong. Code formatting is semantic HTML to indicate to a parser that text is code. If we start lying to our parsers, we break tools built on HTML. Consider screen readers: if a visually impaired user configures their software to spell out code tags, or to have an easy keyboard shortcut with a macro called "jump to next code span/block and highlight" for easy copy-pasting, we are significantly disabling their ability to interact with the page. Further disabling, I should say. Commented Aug 1, 2013 at 5:23
  • @SevenSidedDie: Once upon a time, HTML zealots declared that tables were, in many cases, semantically wrong and that developers should prefer divs with table-like CSS. How did that work out?
    – Jim G.
    Commented Jul 8, 2014 at 11:20
  • 12
    @JimG. Everyone ended up agreeing with them? Commented Jul 8, 2014 at 12:00
  • @DavidMulder: Well, if Bootstrap, Blueprint, 960, and other grid frameworks imply that the table-like divs won, then I suppose you are correct. But when I need a quick table on a page, I simply reach for the table tag.
    – Jim G.
    Commented Jul 8, 2014 at 13:49
  • 4
    @JimG. Tables and code markup are different beasts (one is layout and/or data structure, one styling), so the considerations for their proper use are orthogonal. Trying to argue from one to the other is a non-starter. Commented Jul 8, 2014 at 16:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .