编程语言需要注释吗?

时间:2008-12-24 05:07:40

标签: language-agnostic comments

在对Klingon语言进行了一些愚蠢的思考之后,我发现了一个愚蠢的爱好项目,创建了一个编译为Lua字节码的Klingon编程语言。在初始语言设计阶段,我查找了有关post的信息,并了解了这个克林贡编程规则:

  

真实的克林贡战士不评论他的代码!

所以我决定我的语言不支持评论,因为任何好的克林贡都不会使用它们。

现在许多克林贡方式对我们这些人类程序员来说似乎并不合理,但是在涉及我的爱好语言的设计和实现时,我开始意识到这个关于评论的克林贡规则确实非常合理,即使不是很好。

删除使用编程语言发表评论的功能意味着我 来编写识字代码,没有例外。

所以它让我想知道是否有任何语言不支持评论?

是否有任何非常好的论据可以不删除某种语言的评论?

编辑:需要哪些好的评论示例?


P.S.>我上面的爱好语言无论如何都是愚蠢的,所以不要过多关注我的实现,就像一般的评论概念一样

32 个答案:

答案 0 :(得分:22)

不要评论你在做什么,但为什么你这样做。

通过清晰,可读和简单的代码以及正确选择变量名称来支持它。注释显示代码本身无法(或难以)显示的更高级别的代码结构。

答案 1 :(得分:21)

我不确定我是否赞同“使用编程语言删除注释的能力意味着我必须编写文字代码,没有例外”的声明中的“Have”,因为并不是所有代码都记录在案。我的猜测是,大多数人会编写不可读的代码。

更重要的是,我个人不相信现实世界中自解释程序或API的现实。

我的论文手动分析整个API的文档的经验表明,您经常需要携带比单独签名中传达的信息更多的信息。如果您从您的语言中删除界面注释,有哪些替代方案?没有文档不是一种选择。外部文档不太可能被阅读。

至于内部文档,我可以看到你想要减少文档以说服人们更好地写作的观点。但是,评论有许多协作和协调目的,旨在提高对事物的认识。通过将这些细节排除在外围位置,除非您的工具非常棒,否则您将降低他们未来读者意识的机会。

答案 2 :(得分:12)

呃,在测试期间无法快速注释出一行(或几行),这对我来说很烦人,特别是在编写脚本时。

答案 3 :(得分:7)

一般来说,评论是一个瑕疵,表明设计不佳,特别是漫长的漫无边际评论,显然开发人员并不知道他们在做什么,并试图通过撰写评论来弥补它。

评论有用的地方:

  • 在修复程序旁边留下一个票号,以便将来的程序员可以理解业务需求
  • 解释一个特别棘手的黑客
  • 对一段代码的业务逻辑的评论
  • API文档中的Terse说明,以便第三方可以使用您的API

在所有情况下,程序员都应该努力编写描述性的代码,而不是编写描述写得不好的代码的注释。话虽如此,我认为有很多正当理由认为语言应该而且必须支持评论。

答案 4 :(得分:7)

您的代码有两个不同的受众群体:

  • 编译器
  • 像我们这样的人

如果您选择完全删除评论,那么您所采取的假设是,您将只接受编译器,而不是其他任何内容。

当然,作为克林贡语,你可能不需要评论,因为你不是人。也许你可以通过在IL讲话来向我们清楚地证明你的能力?

答案 5 :(得分:4)

我很好奇。你如何阻止某人声明一个包含注释的静态字符串,然后忽略func / method / procedure / battle /的其余部分的变量?

var useless_comment = "Can we destroy our enemies?"
if (phasers on full) return Qapla'

答案 6 :(得分:3)

语言需要评论。至少95%的评论可以用更清晰的代码替换,但是仍然需要记录,你绝对需要记录是否存在一些外部问题。

如果我没有先考虑是否可以更改代码以消除对代码的需求,我从不写评论,但有时候你不能。

答案 7 :(得分:3)

我是唯一一个为了多种目的而评论几行代码的人吗?

答案 8 :(得分:3)

你的代码中没有需要单个断言,因为在发布模式下,它们都已消失了。但是当C ++没有内置断言时,有人编写了断言宏来替换它。

当然,出于或多或少相同的原因,您也不会需要评论。但是如果你设计一种没有评论的语言,人们就会开始做这样的事情:

HelperFunctionDoesNothing("This is a comment! Blah Blah Blah...");

答案 9 :(得分:3)

虽然默认情况下所有源代码都受版权保护。通常很高兴:

  1. 提醒阅读源代码的人知道其受版权保护

  2. 告诉人们该源代码文件的许可条款是什么

  3. 告诉他们他们是否正在查看受保护的商业秘密

  4. 不幸的是,没有评论,就很难做到这一点。

答案 10 :(得分:2)

虽然人类需要能够对代码进行评论,但语言并非绝对必须直接支持评论:对于大多数语言而言,编写删除一行注释的脚本(例如,所有语言)都是微不足道的以'#'或其他字符开头的行然后运行编译器。

实际上,我很惊讶和失望地得知即使是我最喜欢的深奥编程语言也支持评论:Brainf**kWhitespace。这些语言难以阅读,所以看起来它们不应该支持评论。 (与我最喜欢的另一种深奥的语言相反:LOLCode,这意味着自我记录,在lolcats-speech中)

在这一点上,我会反对其他回答者:我说,忠于你对克林贡语编程语言的看法,并且不支持评论!

答案 11 :(得分:2)

反对评论的一点是,它们往往会与代码过时。每次添加冗余时,都存在这种不一致的风险。

实际上,当一个小组使用NLP来分析某个大型系统中的锁定注释,然后将它们与静态分析的结果进行比较,并且能够通过这种方式修复一些错误时,我发现了一些有趣的研究。

答案 12 :(得分:2)

不是文字编程和代码一样多吗?当然,我所看到的文字编程的大部分内容都有与代码一样多的解释,如果没有更多的评论。

答案 13 :(得分:1)

我认为在很多情况下都需要这些评论。

例如,想一想算法算法。假设有一个用C编写的函数来解决Traveling Salesperson Problem,可以使用各种各样的技术来解决这个问题。而且这些代码通常具有神秘性。

如果没有明确地描述所使用的参数和算法,通过使用注释,几乎不可能重用这段代码。

答案 14 :(得分:1)

评论很有用,因为他们向读取您的代码的人保证 - 可能是“未来你” - 您已经考虑过她的福利。

答案 15 :(得分:1)

不,当然语言不必评论。但是(有用的)程序确实必须有评论...我不同意你的文字代码缺乏评论的想法。一些非常好的代码很容易通过注释来理解,但只有在没有注释的情况下才能理解。

答案 16 :(得分:1)

  

编程语言是否需要注释?

没有。在宏观方案中,编译器不会关心评论,只是希望代码能够降低到较低的公分母。

  

编程语言提供评论构造是否有用?

是。注释对于程序员来说非常有用,而不仅仅是假装他们知道自己在做什么,而是在调试和有用的文档中。

答案 17 :(得分:1)

我们可以不对代码发表评论吗?当然,但这不会让生活更轻松。

答案 18 :(得分:1)

我无法告诉你我对Javadoc的感激之情 - 在评论中设置非常简单。所以至少有一种意义,即评论是有用的。

答案 19 :(得分:1)

您可能会认为使用您的语言编写的开发人员会花费额外的精力来编写清晰的代码,但实际上有责任设计一种如此表达的语言它不需要评论。地狱,甚至英语都不是那样的(我们仍然是括号!)。如果您的语言不是那么设计,它可能会像Brainfuck一样可用,并享受Brainfuck的受欢迎程度和尊重。

我应该添加链接还是被视为注释的链接?

此外,如果人们需要通过劫持字符串和滥用变量名称(除了代表评论之外什么也不做),他们会找到添加评论的方法。你读过 Godel Escher Bach 吗?

答案 20 :(得分:1)

虽然我同意Uri的回应,但我也提出了一种没有评论的语言。 (ichbins。)语言尽可能简单,同时仍然能够干净地表达自己的编译器;因为你可以在没有评论的情况下做到这一点,所以他们被抛弃了。

我正在研究支持评论的修订版,但有点不同:文字编程风格,代码嵌套在文本中,而不是代码中嵌入的注释。它也可能稍后将示例/测试用例作为一流的语言特性。

祝Klingon黑客好运。 : - )

答案 21 :(得分:1)

不 - 没有一种编程语言需要评论。

该语言适用于计算机。评论是针对人类的。你可以写一个0%评论的程序。它会正确或错误地执行。你不能写一个100%评论的程序。它要么不编译 - 没有main()等等,或者,对于脚本语言,什么都不做。

此外,real programmers don't comment their code。就像Klingons一样。

答案 22 :(得分:1)

制作一种不可能发表评论的语言会比你想象的更难。

if (false) {
    print("This is a comment. Chew on that, Klingons!")
}

答案 23 :(得分:1)

完全删除评论工具将是一个坏主意。当然,开发人员必须学会用最少的注释来编写代码,即编写自我记录代码,但是在很多情况下,人们必须解释为什么某些事情正在以某种方式完成。请考虑以下情况:

  • 新开发人员可能会开始维护代码并且原始开发人员已离开/退出项目
  • 规范或市场需求的变化会导致反直觉的内容
  • 复制权通知,特别是如果开源(一些开源库要求您这样做)

根据我的经验,新程序员倾向于更多地评论,并且随着他们开发专业知识,他们的代码往往会变得自我记录和简洁。一般来说,评论应该是关于为什么而不是如何或者是什么。

答案 24 :(得分:0)

我同意你的看法,编写良好的代码不需要任何评论,因为“代码只是程序员可以使用的优秀文档。但这是非常理想的条件,并不是每个人都能编写好的代码。 因此,需要在以后的评论中编写编写良好的代码。

答案 25 :(得分:0)

代码只写一次,但在其生命周期内多次阅读;因此,优化可读性是值得的。从常量到类的所有内容的清晰一致的命名是必要的,但可能或可能不足以实现此目标。如果没有,请用注释填写空白,并按照代码维护它们。

答案 26 :(得分:0)

如果你不需要的话,为什么语言的开发者会添加注释。 评论很有​​用。想象一下测试你的代码在一个函数中出现错误你必须删除整个函数而没有备份如果我是你我只会评论该函数以使编译器避免它如果我在发布日期之前获得该函数的新替代品我将删除该功能。否则我将开始打印调试代码以查看函数的哪一部分有问题。

答案 27 :(得分:0)

任何代码都需要注释,我试着解释我用1或2行写的每个函数的原因和工作原理。

解释自己的代码只存在于一个完美的世界中,总会出现一些奇怪的黑客或者做一些快速肮脏的事情,而不是那种方式。 要记住的最好的事情是评论为什么代码会执行它的功能,优秀的代码解释了它在99%的情况下执行的操作。

写一些简单的东西,比如一段可以解决数独谜题的代码(循环中相当简单的3个)并尝试在3个月之后阅读。你会不经意地找到一些不太清楚的东西。

答案 28 :(得分:0)

完美代码需要零评论。它应该是简单的,并且可以被完整的新手理解。

答案 29 :(得分:0)

我曾经写过一个VB应用程序(一个受大富翁启发的愚蠢棋盘游戏),没有任何评论。但我这样做只是为了惹恼我的老师,他告诉我们的评论是“我们发现相关的,所以我们以后可以记住它。”

答案 30 :(得分:0)

当然!!

主要原因是新手开发者。不是每个人都知道如何编写识字代码。实际上有数百万人在看到它时没有得到NullPointerException。

我们都在某个时刻开始。

但是,如果你只针对“专家”开发人员,那么为什么要首先使用该语言。你应该是using butterflies !!!这就是真正的开发人员使用的!

评论是必须的,如果您愿意,请尽量使其更难(例如使用#// ## / sequence创建评论或类似内容),但不要将其遗漏。

:)

答案 31 :(得分:0)

我认为问题可能会变成没有评论的语言会自成一体吗?例如,如果它编译为在其他代码中使用的DLL,那么除了函数签名之外,如何知道它需要什么,更改和返回?我不希望函数名称是几十个字符,试图用函数上面的注释来表达可以很容易地做的事情,这些注释可以用作Visual Studio中的对象浏览器之类的文档。