在对Klingon语言进行了一些愚蠢的思考后,我发起了一个愚蠢的爱好项目,创建了一个编译为Lua字节码的Klingon编程语言.在初始语言设计阶段,我查找了有关Klingon程序员的信息,并了解了这个Klingon编程规则:
一个真正的克林贡战士不评论他的代码!
所以我决定我的语言不支持评论,因为任何好的克林贡都不会使用它们.
现在许多克林贡方式对我们人类程序员来说似乎并不合理,但是在涉及我的爱好语言的设计和实现时,我开始意识到克林贡关于评论的规则确实非常合理,即使不是很好.
去除编程语言评论的能力意味着我HAVE写有文化的代码,没有例外.
所以它让我想知道是否有任何语言不支持评论？
是否有任何非常好的论据可以不删除某种语言的评论？
编辑:需要评论的任何好例子吗？
PS>上面的我的爱好语言无论如何都是愚蠢的,所以不要过多关注我的实现,就像一般所需的评论概念一样
不要评论你在做什么,但为什么你这样做.
WHAT由清晰,可读和简单的代码处理,并通过适当选择变量名称来支持它.注释显示代码本身不能(或很难)显示的更高级别的代码结构.
我不确定我同意语句中的"Have""删除编程语言的注释能力意味着我必须编写文字代码,没有例外",因为并不是所有代码都记录在案.我的猜测是大多数人会编写不可读的代码.
更重要的是,我个人不相信实际世界中自解释程序或API的现实.
我手工分析整篇API文档的经验表明,您经常需要携带比单独签名更多的信息.如果您从您的语言中删除界面注释,有哪些替代方案？没有文档不是一种选择.外部文档不太可能被阅读.
至于内部文档,我可以看到你想减少文档来说服人们更好地写作的观点.但是,评论有许多协作和协调目的,旨在提高对事物的认识.通过将这些细节排除在外围位置,除非您的工具很棒,否则您将降低他们未来读者意识的机会.
呃,在测试期间无法快速注释出一行(或多行)听起来很烦我,特别是在编写脚本时.
一般来说,评论是一个表明设计不佳的疣,特别是漫长的漫无边际的评论,显然开发人员并不知道他们在做什么,并试图通过撰写评论来弥补它.
评论有用的地方:
在修复程序旁边留下一个票号,以便将来的程序员可以了解业务需求
解释一个特别棘手的黑客
对一段代码的业务逻辑的评论
API文档中的Terse描述,以便第三方可以使用您的API
在任何情况下,程序员都应该努力编写描述性的代码,而不是编写描述编写糟糕的代码的注释.话虽如此,我认为有很多正当理由认为语言应该而且必须支持评论.
您的代码有两个不同的受众群体:
编译器
像我们这样的人类
如果您选择完全删除注释,那么您所采取的假设是您将只满足编译器,而不是其他任何内容.
当然,作为克林贡语,你可能不需要评论,因为你不是人.也许你可以通过在IL讲话来向我们清楚地证明你的能力？
京公网安备 11010802040832号 | 京ICP备19059560号-6 
