我正在维护一个大型的 asp.net 应用程序。
我的目标是确定为响应特定工单而添加的行。虽然可以使用我们的 SVN，但我想将其放入代码中。因为这些更改对于第一次阅读代码的人来说看起来很奇怪。
那么哪种勾勒方法更适合这个目的
{
//response to ticket #xxxxx
...
...
..
}
或
#region response to ticket xxxxx
..
...
..
#endregion
或者有没有其他更适合的方法
【问题讨论】：
标签： c# code-formatting
在两者之间，绝对使用 cmets - 它们非常灵活。区域不适合这种事情——如果多张票需要更改重叠的代码怎么办？这在较长的评论中很容易解释。
但是，无论如何，我反对将这种信息放在 cmets 中。实际上没有人会偶然发现一年前编写的代码并去查票。代码应该是不言自明的，并且在 非常奇怪 不是的情况下，cmets 应该描述代码实际做了什么，而不是为什么。为了解决您对新读者的特殊关注——您的同事不需要证明为什么代码是这样的。他们会认为这是有原因的，并且在进行其他更改时将始终尝试维护现有功能。这是基本的职业行为。
您的变更集应该与票证相关联，以防有人需要历史信息。有一个理由列表，说明为什么事情是它们存储在每个文件中的方式。它存储在您的代码库外部 - 在您的源代码控制或其他存储库中。
根据我的经验，在代码中添加票号通常是不良做法的表现。它表示偏离设计而不是固定设计。票号上写着“这就是代码曾经的样子，而这就是现在的样子。”代码库不应反映它们自己的历史 - 重要的是它们现在的工作方式。
【讨论】：
对选项 1 的响应：为工单添加 cmets 会降低代码的可读性。我认为（我的公司鼓励这样做）当您签入票修复时，您还应该更适当地记录该代码部分，但同样，添加票号可能只是令人困惑。
对选项 2 的回应：区域用于将具有相似目的的功能组合在一起，因此我也不推荐此选项。
建议的选项：使用 /// 标准的注释函数并添加一个这就是更改的内容。元素。这种方式修复不会破坏正常的可读性，但很容易看到与票证相关的功能。作为一个额外的好处，这个机制是自我记录的，所以这些会自动放入你生成的文档中。注意：您可能需要检查是否支持自定义标签。
【讨论】：
尝试一些，看看你的同事是怎么想的。
除了更琐碎的更改之外，您最有可能在您的源代码中分散更改——因此使用 SVN 责备/注释将是最好的选择。
【讨论】：
我们使用 JIRA SVN 插件来直接查看针对特定工单修改了哪些代码文件。
区域可能会变得很麻烦，因为可能会使用一行代码来修复两张票。所以，选择第一个 //ticket #
【讨论】：
第一个选项。 "//响应票#xxxxx"
第一次这样做...
int defaultVal = 12;
到这里……
int defaultVal = 13;
如果您决定采用#region 范式，您将讨厌自己的生活。一/两行代码修复是常态，我从经验中知道过度使用区域会通过不必要地隐藏数据而扰乱您的视觉流程。
最好这样做来隐藏你知道是垃圾的项目。
#region Old Code
//int defaultVal = 12;
#endregion
int defaultVal = 13; //Changed by Ticket:13414
默认情况下新代码可见，而旧代码隐藏。
【讨论】：