大部分时间Markdown文件都被视为源代码：它们在VCS中，它们参与拉取请求和/或评论，并且它们格式正确。就像在源代码中一样，我经常看到特定长度的插入换行符 - 就像代码格式化程序一样。
许多编辑根据当前窗口大小动态执行此操作。此外，Markdown主要用于生成HTML页面，PDF文档或其他格式。在这些情况下，手动插入的换行符通常会导致文本渲染混乱。
那么，将Markdown包装在某个特定的行长度某种反模式还是我错过了什么？
编辑：整个主题似乎是controversial。即使是当前的CommonMark规范（v0.26）也有一定的范围：
不带两个或多个空格或反斜杠的常规换行符（不在代码范围或HTML标记中）被解析为softbreak。 （软件破解可以在HTML中呈现为行结尾或空格。结果在浏览器中也是相同的。在这里的示例中，将使用行结尾。）
[...]
符合标准的解析器可以在HTML中呈现换行符，作为换行符或空格。
渲染器还可以提供一个选项，将软换行符渲染为硬换行符。
然而，John Gruber said早在2004年：
“一个或多个连续文本行”规则的含义是Markdown支持“硬包装”文本段落。这与大多数其他文本到HTML格式化程序（包括Movable Type的“转换换行符”选项）显着不同，后者将段落中的每个换行符转换为
<br />标记。如果您想使用Markdown插入
<br />中断标记，则结束包含两个或多个空格的行，然后键入return。是的，这需要花费更多精力来创建
<br />，但是简单的“每个换行符是<br />”规则对Markdown不起作用。 Markdown的电子邮件风格的区块清单和多段列表项目最好 - 并且看起来更好 - 当您使用硬中断格式化它们时。
答案 0 :(得分：3)
大多数降价渲染器会忽略单行换行符，因此将文本环绕在一些约定的长度上不会影响渲染结果。但是，它可能会使代码更容易维护。这不仅仅是一种反模式，有些项目甚至需要它们的编码标准（例如我的头顶：libstoragemgmt-doc）。
答案 1 :(得分：1)
好与坏总是取决于您的观点和背景。
在我自己改变偏好之后，我认为主要的区别在于你是否将它们存储在 VCS 中，比如 git，或者你是否只是为了“个人使用”而编写和阅读它们。
使用“每行一个句子”会使差异变得“语义化”，因为它只影响发生变化的行/句子。重新格式化整个段落并显示在 git diff 中是......好吧，不好。它用“演示”隐藏了实际的变化。
如果这不是问题，有时较长且参差不齐的行会使阅读和写作变得不那么愉快，因此在 wiki、电子邮件等中，我倾向于使用自动重排和限制行，就像我在打字时一样.
Markdown 实际上不是演示文稿，而是源代码，因此看待它的一种方式是，如果版本控制更重要，我们就不应该太在意源代码的可读性。
但对“降价是源代码”视图的一个警告是，并非所有渲染都将两行文本作为段落呈现，但将换行符保留为“硬换行符”，从而导致结果在视觉上也不吸引人。