Ide 富文本有助于注释代码吗？

我一直想知道为什么我必须在文本编辑器中编写富文本代码注释，也称为伪代码（c'mon，bold，underline！），然后返回IDE（集成？）来编写实际的程序，更不用说确保这些文档与代码保持一致

所以问题是，如果IDE允许富文本代码注释怎么办。这对任何人都有帮助吗？考虑到你可以强调或强调重点并使用标题和子标题，也许可以让模糊的图片更清楚地理解

（是的，我知道我们可以用*要点*和*******头球*******来对付，但让我们先从盒子里想一想

---

我说的是集成在IDE中的RTF代码编辑器。

绝对不是！我只是不相信任何人会在我的代码中使用“特殊字符”来捣乱，这可能有一天会给我带来另一个麻烦

更新：Jeremy指出，在将文件提交给编译器之前，注释（包括任何格式）都会被删除。这很好，但我还是发自内心地不喜欢在代码中添加控制字符

一种有效的方法是ReSharper所做的。当它“查看”您的代码时，它会将任何以“Note：”开头的注释加粗并变成蓝色。这很有用，因为没有人会弄乱我的文本格式-他们只是使用基于内容的颜色编码

---

再次强调：不要更改我的文件格式。但是根据内容突出显示内容是可以的。

您可以检查使用的格式-基本上它使用标记来标记内容，但可以包含链接等。

否，因为如果用户在没有特殊IDE添加的情况下查看代码，则可能无法读取注释

---

但是，我可以理解IDE的可自定义自动格式化。例如，您的IDE可以配置为在Markdown（StackOverflow使用）下处理注释，这样做的好处是具有可读的“代码”

如果你让这个想法通过并流行起来，总有一天你会发现Excel电子表格或视频嵌入到某人的代码中。不，请让源代码，至少源代码！成为纯文本。

一般来说，注释代码的想法是解释你的单个例程（或组件）的操作你不需要用额外的格式化标记这些评论，而其他人可能会认为混乱。

---

如果某个特定部分需要图像、强调或以其他方式需要更深入的解释，则说明需要发布说明或支持文档。我知道，这是开发人员的死敌，但最好保持内容整洁且易于支持。

Javadoc允许使用HTML标记和一系列自定义标记（例如链接到其他类或方法）在过去十年中。

我想要的文档结构与源代码的结构不匹配

例如，功能规范是一个功能列表：每个功能都在一个地方描述……但是功能的实现，例如通过DAL从UI到数据库的事务，在源代码中不在一个地方

此外，不同的人需要不同类型的文档：

• 功能规格是什么
• 用户界面是什么
• 什么是数据设计
• 软件设计是什么
• 开发项目/过程是什么
• 测试用例是什么
• 测试结果如何

imo说，将文档放在与源代码相同的源文件中没有帮助

---

然而，也请参见“识字编程”。我不知道什么是“识字编程”，或者它的本意是什么，但它至少在一个狭窄的情况下看起来很有用，即，当你试图写软件时（例如，写一篇关于某个软件的文章）史蒂夫·麦康奈尔（Steve McConell）引用复杂格式评论的问题是，由于它们需要做更多的修改，因此更容易过时

如果整个团队都采用了富文本编辑IDE，您可能能够绕过这个问题。但您将采用一种勇敢的新代码创建方法，这是大多数团队明智地倾向于避免的，而倾向于采用当前的最佳实践

---

实际的嵌入式文档是另一个问题，我不确定处理这个问题的最佳方法。

我真正希望在注释中使用的富文本是引用其他代码段的超链接。使用Javadoc样式的注释或仅使用CTAG很容易做到这一点

---

如果纯文本注释不清晰，您可能需要更好的文档，而不是更好的文档格式。

我有点喜欢这个想法。由于注释已经是一种颜色，它可能需要一些限制，而不是真正的富文本，或者很难从代码中识别注释。但是如果它只允许粗体、下划线如果您知道代码是一个乱码，或者是一个“永远不要编辑此”类型的注释，那么它将非常有用

但是，只有当它成为一个通用且广泛使用的IDE的一部分时，它才会起作用。

实际上，注释代码的真正帮助是当语言采用最常用的注释模式并将其转化为语言功能时：

final

关键字可以删除此类注释：

// Don't extend this class! Ever!

抽象方法取代了这一点：

// make sure you implement foo() bar() and baz() in all child classes

好的面向对象编程将组织代码，这样您就不需要大而烦人的标题：

// *******************************************
// ***** Input Handling here *****************
// *******************************************
// * This next section has all the functions *
// * dealing with keyboard input.            *
// *******************************************

…变成

class InputHandler {
    // This class deals with keyboard input.
}

---

这是一个有趣的问题，因为除了它现在是否真的是一个好主意之外，它还突破了我们工作方式的界限

所有不混合富文本和代码的原因都没有解决这样做是否有助于任何人的问题——是否也有弥补缺点的有利方面。也许我们会