每个人工创建的代码文件的开头都有文件头注释吗？
我正在阅读All-In-One Code Framework Coding Standards文档，其中一个建议是在每个人工创建的代码文件的开头添加文件头注释。 这是我第一次看到这样的推荐，对我来说这只是一个不必要的丑陋的混乱，但我想知道是否有人可以解释为什么M $推荐这个？
他们的例子如下：
/****************************** Module Header ******************************\ Module Name: Project: Copyright (c) Microsoft Corporation. This source is subject to the Microsoft Public License. See http://www.microsoft.com/opensource/licenses.mspx#Ms-PL. All other rights reserved. THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. \***************************************************************************/ 就个人而言，除非您有理由在您的代码中加入法律免责声明（例如，如果您将开源或将其与产品一起分发），我发现在每个源文件中都有一个共同的标题是有限的。 有时，如果您包含来自第三方或开源项目的源代码，您可能有义务包含有关该代码的免责声明和原产地声明。
相反，我更喜欢使用C＃XML代码注释，并将我的文档集中在类型和类上，而不是“模块”或代码文件。 与类型（或方法或枚举等）一起生活的文档不太可能变得陈旧并提供更好的粒度。 还有许多工具可以将这些注释转换为文档，或者使用它来提供智能感知支持。
从历史上看，这种做法起源于全球函数，常数和结构几乎可以存在于任何地方的语言; 并且通常会因组织或编译依赖性原因而共处一地。 这些在托管/ .NET世界中几乎完全不相关。
这对于开源项目，设计用于在其他项目中重复使用的代码文件以及其他人/公司等通常很有用。例如，在代码不离开公司的封闭式企业环境中，它并不是特别有用。 ，团队始终在一起工作并相互了解，不一定是“项目”，而只是对核心产品的持续改变/增强等。
与大多数推荐的这种性质的编码标准一样，这是一个判断调用。
这不是一个不寻常的建议。 例如，Apache要求许可信息也包含在每个源代码文件中：
http://www.apache.org/legal/src-headers.html
造成这种情况的原因各不相同，但为了对它们进行合理的讨论，请查看：
将许可证放在每个代码文件中？
许多项目不会对每个源文件执行任何操作，但是基于每个源文件遵循此策略的原因之一是（直接来自上面关于SO的讨论）：
“基本上，你所取得的成就是人们不小心违反许可条款的风险较低。你必须决定对你有多重要。”
我遵循这个标准只是因为它让你知道文件在第一眼就看到了什么。 当然，如果编写标题的人努力编写一个好的描述，但我通常会这样做以及添加修改部分以记录文件的任何重大更改。
这旨在满足法律要求。
这不是技术目的。
您正在阅读Microsoft明确公开使用的源代码的编码标准，作为人们查看和复制的样本。 将这种类型的代码拆分成单独的文件是常见的和期望的，因此每个文件中存在许可信息是重要的。
正如其他人所说的那样 – 对于预计不会公开的项目，通常不需要这样的标题。