您的代码中的注释页眉和页脚是否真的有必要?

时间:2009-04-05 11:23:58

标签: comments

许多公司编码标准要求在每个文件中都有一个大的注释页眉和页脚。类似的东西:

// MyFile.cpp
//
//  Copyright (c) 200x Company ABC
// 
//  This file is a copyrighted... blah blah blah
//

<... some code ...>

// Copyright (c) 200x Company ABC
//
//  Change history:
//     1.0  -  Blah
//     1.1  -  Blah, blah..

所以,问题是 - 为什么我们需要这个?这是否真的有必要声明文件内容的版权,或者这是一个误入歧途的做法已成为标准? 那里有人为一家不需要这样的公司工作吗?

10 个答案:

答案 0 :(得分:20)

首先,更改历史记录毫无意义,请使用您的SCM。

版权声明并非严格要求(版权是自动的) 1 ,但如果您要发布源代码,那么可能包括它将被认为更安全 2 。完整的许可证声明可能在单独的文件中更好,然后引用(这是Boost所做的)。

1 Wikipedia有一个合理的摘要,但你真的需要自己的法律建议。

2 特别是律师安全地玩。

答案 1 :(得分:9)

我的公司不需要这个......并且更改历史记录的位置应该在源代码控件中而不是代码文件中。

答案 2 :(得分:4)

我在一家非常大的软件公司工作,有许多奇怪的标准。

其中之一。我们不需要在源代码中添加任何页眉或页脚。不需要在每个类文件中声明版权。更不用说修订版,由任何可用的源控制管理系统处理。

答案 3 :(得分:4)

在我实习的公司里,我们在所有源文件中都使用了这些标准评论标题 - 男孩他们烦我。每次我必须阅读一个新的源代码文件时,由于每个文件的所有更改历史记录,我必须向下滚动1或2个屏幕长度。在那里的6个月里,我从未使用过变化历史,从未见过任何人。

我个人的观点是,你不应该把你很少需要的东西放在这样的地方。你需要在某个地方拥有改变历史和类似的东西,但它应该是你可以查找的地方,以防你真正需要它。如果您坚持将其嵌入源文件中,也许在页脚中?

标准标题评论很痛苦,应该是非常简约甚至更好的不存在。把那个巨大的ASCII艺术品扔到页脚或者自述文件中,我不在乎,但是,请保留我的标题:)

如果您搜索结果的前800个像素中包含一些巨大的Google徽标和版权声明,您认为谷歌会取得成功吗? :P

答案 4 :(得分:4)

有兴趣看到Google require关于其C ++资源的版权声明。这对我来说似乎总是多余的,特别是考虑到文件将(希望!)备份并且也驻留在源代码管理中,以防版权争议随之而来。我也不确定用作者的名字来标记来源:其他人是否需要请求编辑/使用该文件的权限?!

源代码控制绝对不需要更改历史记录页脚,以及我亲眼目睹了人们评论旧代码并将其留在那里的奇怪做法!好的SCM软件可以让你浏览文件修订版并提供版本比较。好问题:)

答案 5 :(得分:2)

标题中的更改历史记录要求可能是在它们具有更改历史记录系统之前的剩余部分。我曾经使用过手动制作注释的系统,并且会在源代码管理系统中创建虚假的更改!

我目前在哪里工作,代码文件页眉或页脚中不需要版权和更改历史记录。

答案 6 :(得分:1)

我在一家公司工作,我们不需要这个。我们默认拥有版权,因此它只是源文件中不必要的文本噪音。

更改历史记录可能很有用,但非常有限。如果你试图记录你改变的每个分号或运算符,那么它很快就会变老。此外,更改历史记录并未提供有关特定作者更改内容的详细信息。更确切地说,谁来到这里并做了些什么。

答案 7 :(得分:1)

没有必要声明版权(取决于管辖权)。您通常会自动拥有作品的版权。

对于合作中的代码,知道如何在源文件上做什么以及什么时候总是很好。

如果没有某种页眉/页脚组合,我从未见过内部代码。

答案 8 :(得分:1)

如果符合企业标准,我们根本就没有。但是,尽管如此,当这个文件应该被分发或者应该被其他设施使用时,我们会在每个文件的开头添加版权声明和联系人数据。它有助于反馈收集。

答案 9 :(得分:1)

很多东西都是历史遗留物。但这并不意味着它没用。

评论文件上的更改是没有意义的,多年前该文件已停止成为代码组织的单位。我把标题放在我的函数上,但这是为了解释函数/方法的目的(加上它使代码更容易扫描)。我还在这些函数头中添加了简洁的更改历史......不是因为代码中的更改历史记录是必要的,而是因为SCM系统并不完美,而且我之前看到SCM数据库丢失了。就像备份一样 - 只有在你开始每天担心这些东西之前,灾难才会发生在你身上。

我的工作伙伴让我疯狂,因为他们虔诚地依赖SCM跟踪他们的变化,但是没有在SCM 中添加适当的评论。因此,当不可避免的管理问题后故障分析发生时,他们必须坐在那里几个小时,试图找出为什么他们三年前做出了一个特定的改变。