2008-12-24 90 views
21

经过对克林贡语言的一些愚蠢的思考后,来自这个post我开始了一个愚蠢的爱好项目,创建一个编译为Lua字节码的克林贡编程语言。在最初的语言设计阶段我抬起头来有关Klingon programmers,并发现了这个克林贡语的编程规则:编程语言需要注释吗?

一个真正的克林贡勇士不评论他的代码!

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

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

删除从一种编程语言评论的能力意味着我HAVE识字码,没有例外。

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

是否有任何非常好的论点不从语言中删除评论?

编辑:任何需要评论的好例子?


PS>我的爱好之上的语言是部分傻反正,所以不要过于注重我的实现,尽可能的在一般

+0

有时我的英语需要评论。我想我不是克林贡。 – 2008-12-24 05:51:43

+1

这应该是关闭的 – Foredecker 2008-12-24 06:08:03

+1

你为什么说它应该关闭?似乎完全是与我有关的程序设计,似乎不太可能是现有问题的重复。 – 2008-12-24 06:28:52

回答

20

我不确定我是否同意这个陈述中的“有”:“从编程语言中删除评论的能力意味着我必须编写识字代码,没有例外”,因为它不像所有的代码都被记录。我的猜测是,大多数人会写不可读的代码。

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

我从手工分析论文的整个API文档的经验表明,你经常需要携带更多的信息,而不是单单在签名中传达的信息。如果您从您的语言中删除界面评论,还有什么选择?没有文件不是一个选项。外部文档不太可能被读取。至于内部文档,我可以看到你想减少文档以说服人们写得更好的观点。然而,评论服务于许多协作和协调目的,旨在提高对事物的认识。通过将这些细节消除到外部位置,您将减少未来读者意识到的机会,除非您的工具很棒。

+0

+1因为不得不外部化文档依赖性是支持评论的重要一点。 – 2008-12-24 05:24:27

+0

谢谢。这通常是一个问题:如果人们不知道它们存在,人们就不会去寻找。我的很多研究都集中在人们是否调查方法文档的问题上,看他们是否传达了任何重要的东西 - 它们不是,这会导致严重的问题。 – Uri 2008-12-24 05:37:20

1

需要注释的概念,你可能会认为开发商编写您的语言将会额外付出努力去编写明确的代码,但实际上您的设计的语言是所以表示它不需要评论。地狱,甚至连英文都不是这样(我们仍然括号!)。如果你的语言设计得不那么完美,它可能会像Brainfuck一样可用,并享受Brainfuck的知名度和尊重。

我应该添加链接还是链接被认为是评论性的?

此外,如果需要通过劫持字符串和滥用变量名称(除了代表注释以外别无他用),人们将找到添加注释的方法。你有没有读过Godel Escher Bach

+0

好的可敬性并不是这里的主要问题,但除此之外,我想不出任何需要表达性的语言特征,你有没有什么好的例子? – 2008-12-24 05:14:00

+0

AFAIK,所有语言解析器都忽略注释,因为它们用于自然语言编写,这些语言具有表达性,但是由于编写确定性解析器而过于依赖上下文。 – 2008-12-24 05:19:25

+0

还没有读过GED,但看起来像一个很好的阅读。要订购:) – 2008-12-24 06:58:12

0

我认为这个问题可能会变得没有意见的语言是独立的吗?例如,如果它编译成在其他代码中使用的DLL,那么除了函数签名之外,如何知道它需要什么,更改和返回的内容?我不希望函数名称为数十个字符,以试图表达可能非常容易完成的注释,该注释可用作Visual Studio中的对象浏览器等文档中的函数。

3

语言需要注释。至少有95%的评论可以用更清晰的代码替代,但仍然有假设需要记录,并且如果存在某些外部问题,您绝对需要记录这些假设。

我从来没有写第一个评论,如果我可以改变代码来消除它的需要,但有时你不能。

7

一般来说,评论是一种瑕疵,表明设计不佳,特别是漫长的漫长评论,其中明确的开发人员不知道他们在做什么,并试图通过写评论来弥补。

邻居那里的意见是有用的:

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

在任何情况下,程序员都应该努力编写描述性的代码,而不是编写描述写得不好的代码的注释。这就是说,我认为语言应该并且必须支持评论有很多有效的理由。

+0

+1为真实的例子,特别是票(和TODO有关) – 2008-12-24 05:29:29

+0

门票和TODO可以纳入语言。事实上,这将是非常棒的。 – 2008-12-24 05:48:11

+0

您的权利Marxidad,TODO和门票可以类似于Deprecatation完成,伟大的想法将将其纳入我的设计 – 2008-12-24 05:54:45

7

你的代码中有两种不同的受众:

  • 编译器
  • 人类和我们一样

如果选择完全删除评论,你正在服用的假设是,你会只适用于编译器,并没有别的。

当然,作为克林贡,你可能不需要评论,因为你不是人。也许你可以用IL来说明我们的能力吗?

+0

对于人类观众+1 +1 – 2008-12-24 05:27:50

21

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

什么是由干净,可读和简单的代码照顾妥当的变量名称选择来支持它。注释显示代码本身不能(或难以显示)的代码的更高级别的结构。

2

尽管人们需要能够评论代码,但语言并不一定需要直接支持评论:对于大多数语言来说,编写一个删除一行注释的脚本将是微不足道的(例如,所有以'#'或其他字符开头的行)然后运行编译器。

其实,虽然我很惊讶,也很失望,得知即使我最喜欢的深奥编程语言也支持评论:Brainf**kWhitespace。这些语言的目的是难以阅读,所以它们似乎不应该支持评论。 (相对于我的其他最喜欢的深奥语言:LOLCode,这意味着要自我记录,用lolcats-speech)

我会在这一点上对其他回答者持不同意见:我说,要忠于你对一种克林贡编程语言,并且不支持评论!

1

完全删除评论工具将是一个坏主意。当然,开发人员必须学会用最少的注释来编写代码,即编写自我记录的代码,但在很多情况下,必须解释为什么要按照原样进行操作。考虑以下情况:

  • 一个新的开发者可能会开始维护代码和原始开发已经离开/出该项目的
  • 在规范或市场需求的变化导致的东西,是反直觉的
  • 复制权通知,特别是如果开源(一些开源库需要你这样做)

这也是我的经验,新的程序员往往多加评论,并为他们开发的专业知识他们的代码会变得自我记录和简洁。一般来说评论应该是关于为什么而不是如何或什么。

0

当然!!

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

我们都在某个时候开始。

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

评论是必须的,如果你想(如使用#// ##/sequence创建注释或类似的东西)但不要忽略它,尽量让它更难。

:)

1

不 - 没有一种编程语言需要注释。

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

另外,还有real programmers don't comment their code。就像克林贡一样。

2

反对意见的一点是,他们倾向于经常与代码过时。无论何时添加冗余,您都会冒这种不一致的风险。

实际上,当一个小组使用NLP分析某些大型系统中的锁定注释,然后将它们与静态分析的结果进行比较并能够修复一些错误时,我已经看到了一些有趣的研究。

11

呃,在测试过程中无法快速地注释掉一行(或多行)听起来令人厌烦,尤其是在脚本编写时。

1

是否需要编程语言的注释?

不可以。在事物的宏观方案中,编译器不会在乎某个注释,只是希望代码研究到一个较低的公分母。

编程语言提供注释构造有用吗?

是的。评论对于程序员来说非常有用,而不仅仅是假装他们知道他们在做什么,而且在调试和有用的文档编制方面也是如此。

1

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

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

祝你好运克林贡黑客。 :-)

2

是不是文字编程尽可能多的评论,因为它是代码?当然,我所见过的文学编程的很多内容都与代码一样多,但如果没有更多的评论。

0

我同意你的观点,很好的书面代码并不需要任何评论,因为“代码只是程序员可用的良好文档,但这是非常理想的条件,并非所有人都能一次写好代码 因此,在未来的评论好需要

1

我不能告诉你我是多么感激的Javadoc - 。这是非常简单的注释中设立所以这是至少一个意义上的意见是有用的

0

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

1

不,当然一种语言不必评论。但一个(有用的)程序必须有评论......我不同意你的观点,即识字代码缺乏评论。一些非常好的代码很容易理解评论,但只有在没有评论的情况下才能理解。

3

尽管所有源代码默认都受版权保护。它往往是不错的:

  1. 提醒人阅读源代码,这是受版权保护

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

  3. 告诉他们不管他们是否正在寻找受保护的商业机密

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

3

您不需要需要您的代码中有一个断言,因为在发布模式下,它们全都不见了。但是,当C++没有内置断言时,有人编写assert宏来替换它。

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

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

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

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

我觉得在很多情况下都需要注释。

例如,算法的思考。假设有一个用C编写的函数来解决Traveling Salesperson Problem,有很多技术可以用来解决这个问题。这些代码的性质通常是神秘的。

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

3

我是唯一一个注释掉几行代码出于多种目的吗?

0

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

0

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

解释自身的代码只存在于完美的世界中,总会有一些奇怪的黑客或者做一些事情的原因,而不是普通的方式。 要记住的最好的事情是评论为什么代码做它做的事情,好的代码解释了它在99%的时间内做了什么。

写一些简单的东西,比如一段可以解决数独谜题的代码(3个合理简单的while循环),并尝试在3个月后阅读。你会立即发现一些不完全清楚的东西。

1

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

0

代码只写一次,但在其生命周期内读取多次;因此它为优化可读性而付出代价。从常量到类别的所有内容的清晰和一致的命名是必要的,但可能或可能不足以实现此目标。如果没有,请填写留言和留言,并按照代码进行维护。

1

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

1

这将比你想象的更难做一个评论是不可能的语言。

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