内部源代码文档

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

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

根据语言规范,关键字“你忠实的学生”(包括逗号但不包括下面的空格)被用作类定义的结束标记,下面的名称是没有语法效果的注释。

作者被自动包含在每个文件中(如果不是严格要求的话),这让我怀疑它是否可以用作类似于Java Docs的可解释文档的形式。 换句话说,其他程序或编辑将能够解析出这个名字并以某种方式使用它。

  • 这种内部评论文件的要求是什么? 在这种特定类型的语法中是否有会导致问题的东西?

  • 关键字是否足以符合主题? 对我而言,缺乏使用“你忠实的学生”作为复数形式(或者可能是“你忠实的”,或者“真正的你”,因为一个模棱两可的版本)的能力会让多个作者看起来很尴尬和不自然看起来像一封自然人文信是其中一个核心设计范例)。

  • 如果考虑创建Java Docs方法,那么还应该包含哪些其他功能? 首先,日期似乎很常见。 在信的顶部加上某种形式的日期评论可能会看起来很自然,并不违反设计范例。

  • 由于语言是新的,对大多数人来说都不熟悉,而且很愚蠢,所以这里有几个需要考虑的资源:

    原始版本公告

    十月后续


    对不起,没有人给我这个担忧! 我正在开发语言,所以我认为我对这个答案有很好的把握。

  • 这种内部评论文件的要求是什么? 在这种特定类型的语法中是否有会导致问题的东西?
  • 我从未考虑像Javadoc这样的自动文档技术,因此没有正式的语法。 我正在编写的编译器完全放弃了注释,所以它不会支持它,但我相信它不会太难。

  • 关键字是否足以符合主题? 对我而言,缺乏使用“你忠实的学生”作为复数形式(或者可能是“你忠实的”,或者“真正的你”,因为一个模棱两可的版本)的能力会让多个作者看起来很尴尬和不自然看起来像一个自然的小马写的字母是核心设计范例之一)。
  • 最后一行作者姓名的想法是针对该报告的最重要的作者,因此以前从未建议多位作者。 但是, Your faithful students,会很好地工作!

  • 如果考虑创建Java Docs方法,那么还应该包含哪些其他功能? 首先,日期似乎很常见。 在信的顶部加上某种形式的日期评论可能会看起来很自然,并不违反设计范例。
  • 确实! 也许是报告底部的一些内容,比如

    (Written 2013-04-11)
    

    希望这对你有所帮助。 你也有一些很棒的点子,在这里! 你应该加入团队!

    链接地址: http://www.djcxy.com/p/85317.html

    上一篇: Internal Source Code Documentation

    下一篇: How to check if type of a variable is string?