inline code spans强调某些关键字，但不是实际代码。例如：
我在iOS中执行后台任务时遇到了困难。我似乎要面对的问题是，如果我的后台任务运行时间过长，iOS会静默终止该应用程序。如何增加时间，iOS将等待我的后台任务完成？
被编辑为：
我遇到了困难在
background task中使用iOS的时间。我似乎要面对的问题是，如果我的iOS运行时间过长，则background task会静默终止该应用程序。我该怎么做才能增加时间iOS会等待我的background task完成？它分心。进行这些编辑的例子很多。他们经常获得批准，从而加强了这种行为。这是对内联代码范围的有效使用吗？如果不是，是否应该对其进行编辑和更正？建议这些更改的编辑是否应该被拒绝？
#1 楼
正确，应该将它们用于代码（和类似代码的工件）。如果这是唯一的更改，并且应用错误，则拒绝“无任何改进”或“造成危害”。
我对文件名，路径，API方法，命令等没有任何问题。这些是计算机化的“工件”，应与说明文字区别开来。产品，商标等不是必需的。
当需要对非人工制品进行强调或说明时，我们会使用斜体和粗体。
评论
我同意，但是“计算机事物”往往是导致问题的原因。 iOS是“计算机”的东西吗？是。应该是代码范围吗？没有。
–vcsjones
2012年6月8日15:57
@vcsjones不，不是，因为它不是您要作为命令输入计算机或从计算机获取的内容。
–戴夫·牛顿
2012年6月8日下午16:26
我完全同意这一点，并且几个月来一直将其用作拒绝编辑的依据（或者我自己进行编辑以撤消/更改的原因）。
–研究员
2012年6月10日19:06
（对下降投票感到好奇；有什么分歧？）
–戴夫·牛顿
13年2月1日，0：23
我同意AFA“用于代码（和类似代码的工件）”；但我不同意AFA的“唯一更改”，该更改对于提高IMO的可读性仍然有用；而且它仍必须满足6个字符的下限（例如，至少3个未反引号的代码或类似代码的工件）。如果“使用错误”，我再次表示同意；那是不同的-仅仅是错误的，因此没有用。
– J0e3gan
13年4月21日在14:52
@ J0e3gan除了格式化甚至几个关键字都无法达到最低要求之外：这样的编辑会阻塞审阅队列，并且意义不大，不足以使人认可。国际海事组织，这种改进应该留在不再需要对其编辑进行批准的范围之内。请注意，我在该句子中使用了逻辑运算符“和”，并且我打算这样做。
–戴夫·牛顿
13年4月21日在14:53
@vcsjones提出了一个很好的观点； Dave Newton的后续评论很好。但模棱两可的答案来自答案中的计算机“人工制品”。我认为答案一开始就使用类似代码的工件一词。
– J0e3gan
13年4月21日在14:59
@ J0e3gan我毫不含糊：iOS是一种产品，与我列出的其他计算机工件明显区分开。对此无能为力。但有它。
–戴夫·牛顿
13年4月21日在15:04
为什么拒绝琐碎？拒绝带有链接到该问题和答案的自定义消息会更有用吗？例如。内联代码范围不应用于强调。参见http://meta.stackexchange.com/questions/135112/inline-code-spans-should-not-be-used-for-emphasis-right
–马克·阿默里（Mark Amery）
13年7月28日在16:56
@MarkAmery因为（a）一天只有几个小时，并且（b）这个答案作为事实上的答复才存在，直到我写完并被人们投票为止。
–戴夫·牛顿
13年7月28日在19:44
我看到如此多的修改几乎应该是预设的答案，反引号的使用不当
–mcfedr
16-2-29在9:42
由于我对使用反引号进行强调感到内（（而且，从来没有因为这样做而拒绝过任何编辑，所以我真的认为这是使用它的正确方法），我要求澄清一下：突出显示System.Reflection可以，因为它是一个.NET命名空间，但不会突出显示WinForms，因为这是特定工具箱的名称吗？
– waka
17年9月15日在15:13
@waka（°_o）/¯对于WinForms，我可能不会使用反引号，但对于System.Windows.Forms，我会使用反引号。我的意思是，如果您在散文中使用强调，则不要等宽字体，而是大胆或斜体，对吗？
–戴夫·牛顿
17 Sep 15 '17：22
@DaveNewton：是的，现在您提到它，这确实有意义。我不知道我在哪里养成这种习惯，但是我将确保从现在开始这样做。 :)
– waka
17年9月15日在18:45
#2 楼
我认为代码标记应用于实际代码或代码关键字。我会拒绝或还原这样的编辑。我做的一个例外是文件名和路径，因为我认为它们应该被偏移，并且我认为可以说文件系统命令是代码。
#3 楼
来自@SevenSidedDie的评论，应该在自己的回答中，而不是在严重低估的回答下掩埋在评论中：[使用反引号不只是分散注意力，它是语义上错误。代码格式化是语义HTML，用于向解析器指示文本是代码。如果我们开始对解析器撒谎，就会破坏基于HTML的工具。考虑使用屏幕阅读器：如果视力障碍的用户将其软件配置为拼写代码标签，或者具有易于操作的键盘快捷键以及名为“跳转到下一个代码跨度/块并突出显示”的宏以方便复制粘贴，那么我们将严重禁用他们与页面互动的能力。我应该说进一步的禁用。
#4 楼
除了使用内联代码范围突出显示实际代码外，您还可以使用它们来避免文本的解析方式不同，例如以避免将<body>解析为HTML，并呈现为。 （它实际上是不被渲染的，因为它被剥离了。）对于在Markdown中以特定方式渲染的文本也是如此，例如*example*如果没有内联代码跨度，则将作为示例。在其他情况下，不应使用内联代码范围来突出显示纯文字；为此，已经有了粗体和斜体样式，可以使用Markdown轻松获得。
如果建议的编辑仅限于此，则应拒绝；如果建议的编辑不只是这样，则应改进它，以删除不恰当使用的内联代码范围。这些话也是可以接受的。更改将是样式的更改，等同于将引用样式从美式样式改为英式样式，例如以下句子。
她说：“我
她说：“我迟到了”，然后关了门。
如此，建议的编辑应被拒绝，因为这将使样式从可接受的样式更改为可接受的样式，而不会使文本更清晰。
评论
（尽管我要补充的是已经是类似代码的工件，因此它是适当的，并且*斜体*可以用反斜杠转义。）
–戴夫·牛顿
13年2月1日，0：24
#5 楼
使用反引号只是一种强调形式，而不仅限于代码。问题是您的示例使用了过多的强调，而不是不是代码。例如，在Meta上，我使用它们来突出显示徽章名称，因为我们没有Markdown但对于徽章来说。
我也用它们代替引号来强调带引号的术语（不是整个句子）。
评论
粗体和斜体就足够了，不需要第三种形式的强调。
–影子向导正在接种疫苗
2013年1月31日15:06
在我看来，使用徽章名称似乎不是“错”，但值得一提的是，反引号不仅是一种强调形式，它们还具有使文本等距的独特功能（这当然使它们成为代码的理想选择） ）。当间距出现在句子中部时，这种间距变化只会分散注意力（至少在我看来），例如给出的示例。
–杰克·道格拉斯（Jack Douglas）
2013年1月31日15:39
@JackDouglas，是的，我同意这有点让人分心，但并不是强调会分散注意力。我绝对不喜欢看到它被滥用。
–兰斯·罗伯茨（Lance Roberts）
2013年1月31日15:41
对我来说，“太多”等于“大于零”。即使在上面的示例中仅将“ iOS”放入反引号，那也会让我感到困扰。 （尤其是对于建议的编辑。）
– Arjan
2013年1月31日17:43
@Arjan，是的，我认为该摘录不需要任何突出显示。
–兰斯·罗伯茨（Lance Roberts）
13年1月31日在17:45
我认为我将用于徽章，尽管我从未真正尝试过。
–戴夫·牛顿
13年2月1日，0：26
@LanceRoberts这不仅使人分心，而且在语义上也是错误的。代码格式化是语义HTML，用于向解析器指示文本是代码。如果我们开始对解析器撒谎，就会破坏基于HTML的工具。考虑使用屏幕阅读器：如果视力障碍的用户将其软件配置为拼写代码标签，或者具有易于操作的键盘快捷键以及名为“跳转到下一个代码跨度/块并突出显示”的宏以方便复制粘贴，那么我们将严重禁用他们与页面互动的能力。我应该说进一步的禁用。
–SevenSidedDie
13年8月1日在5:23
@SevenSidedDie：很久以前，HTML狂热者宣称表在语义上是错误的，并且开发人员应该更喜欢具有表式CSS的div。怎么解决的？
– Jim G.
2014年7月8日在11:20
@吉姆每个人最终都同意他们吗？
– David Mulder
2014年7月8日12:00
@DavidMulder：好吧，如果Bootstrap，Blueprint，960和其他网格框架暗示以表格形式的div获胜，那么我想你是正确的。但是，当我需要在页面上显示快速表格时，只需到达表格标签即可。
– Jim G.
2014年7月8日13:49
@吉姆表和代码标记是不同的野兽（一种是布局和/或数据结构，一种是样式），因此正确使用它们的注意事项是正交的。试图彼此争辩是没有开始的。
–SevenSidedDie
2014年7月8日在16:23
评论
如果要在帖子中修复其他内容，我会进行修改。带有斜体和粗体以及强调和换行等标题，实际上并不需要任何其他内容，这只会使帖子更难以阅读。后台任务看起来根本不像有效代码。但是我认为代码的额外清晰度应该不容忽视。
有趣;通常我会以相反的方式遇到它-张贴者使用强调来表示代码。
谁批准这些修改？批准者的写作风格与编辑者相同吗？那我就不会感到惊讶。无论哪种方式，这些编辑都是无效的，应完全拒绝（如果批准，则将其还原）。
我也在寻找使用内联代码范围作为注释中内联引号的人。
@BoltClock我不知道这个想法最初是从哪里来的；对我来说这似乎很糟糕，许多人似乎认为这是一个好主意。 （它们似乎确实集中在南亚，但这可能是由于我倾向于编辑评论。）
我对这种无聊的事感到烦恼（有人建议编辑，而有人赞成这样的建议），我提出了一个问题：meta.stackexchange.com/questions/137755 / ...不过，您应该点击那里的链接，因为我的建议不是很好。我想我只是想提出一个要点:)
相关：meta.stackexchange.com/questions/141089/…
相关：请不要使用𝚖𝚘𝚗𝚘𝚜𝚙𝚊𝚌𝚎𝚍或ˋ来强调。这就是斜体的意思，除其他外。而且，当您使用它时，也可以轻松使用粗体。
相关：meta.gaming.stackexchange.com/q/7437