内部源代码文档 - FiM++ [关闭]

Question

FiM++ 程序的结构要求它以字母结尾和代码作者姓名以特定方式结束。

Dear Princess Celestia and Stack Exchange and String: A Sample:
    ...
Your faithful student, Southpaw Hare!

根据language specification，关键字“你忠实的学生”（包括逗号但不包括后面的空格）用作类定义的结束标记，后面的名称是没有语法效果的注释。

作者自动包含在每个文件中（如果不是严格要求的话）这一事实让我想知道它是否可以用作类似于 Java Docs 的可解释文档的形式。换句话说，其他程序或编辑器将能够解析出此名称并以某种方式使用它。

1. 这种基于注释的内部文档的要求是什么？这种特定类型的语法有什么会导致问题的吗？

2. 关键字是否足以适合主题？我突然想到，如果无法使用“您忠实的学生”作为复数形式（或者可能是“您忠实的学生”或“您的忠实”作为模棱两可的版本），列出多个作者会显得尴尬和不自然（并且看起来像一个自然的人类书写的字母是核心设计范式之一）。

3. 如果考虑创建 Java Docs 方法，那么还应包括哪些其他功能？一方面，约会似乎很常见。在字母顶部包含某种形式的日期注释可能看起来很自然，并且不会违反设计范式。

由于该语言是新的，大多数人不熟悉，而且老实说很愚蠢，所以这里有一些资源可供考虑：

Original Release Announcement

October Followup

Answer 1

抱歉，在我之前没有人对此给予任何关注！ 我正在开发语言，所以我想我已经很好地掌握了答案。

1. 这种基于内部评论的要求是什么 文件？这种特殊类型有什么东西吗 会导致问题的语法？

我从未考虑过像 Javadoc 这样的自动文档技术，因此没有正式的语法。我正在研究的编译器完全丢弃了 cmets，因此它不会支持它，但我相信它不会非常难。

1. 关键字是否足以适合主题？它发生在我身上 缺乏使用“您忠实的学生”的能力 复数形式（或可能是“您的忠实”或“您的真实” 模棱两可的版本）会使列出多个作者看起来很尴尬 和不自然的（看起来像一封自然的小马写的信是一个 核心设计范例）。

最后一行作者姓名的想法是针对报告的第一作者，因此之前从未建议过多个作者。但是，Your faithful students, 会很好用！

1. 如果考虑创建 Java Docs 方法，那么还有什么其他的 应该包括功能？一方面，约会似乎很常见。包含 信函顶部的某种形式的日期注释可能会 看起来很自然，不违背设计范式。

确实！也许在报告的底部有一些东西，比如

(Written 2013-04-11)

希望这对您有所帮助。你也有一些很棒的想法！你应该加入团队！