我正在维护一个大型的 asp.net 应用程序。
我的目标是确定为响应特定票证而添加的行。虽然可以使用我们的 SVN,但我想将其放入代码中。因为对于第一次阅读代码的人来说,这些更改看起来很奇怪。
那么哪种勾画方法更适合这个目的
{
//response to ticket #xxxxx
...
...
..
}
或者
#region response to ticket xxxxx
..
...
..
#endregion
或者有没有其他更适合这个的方法
我正在维护一个大型的 asp.net 应用程序。
我的目标是确定为响应特定票证而添加的行。虽然可以使用我们的 SVN,但我想将其放入代码中。因为对于第一次阅读代码的人来说,这些更改看起来很奇怪。
那么哪种勾画方法更适合这个目的
{
//response to ticket #xxxxx
...
...
..
}
或者
#region response to ticket xxxxx
..
...
..
#endregion
或者有没有其他更适合这个的方法
在两者之间,一定要使用注释——它们非常灵活。区域不适合这种事情——如果多张票需要更改重叠的代码怎么办?这在较长的评论中很容易解释。
但是,无论如何,我反对将这种信息放在评论中。实际上没有人会偶然发现一年前编写的代码并去查票。代码应该是不言自明的,在非常奇怪的情况下,注释应该描述代码实际做了什么,而不是为什么。为了解决您对新读者的特定关注 - 您的同事不需要证明代码为什么是这样的。他们会认为这是有原因的,并且在进行其他更改时将始终尝试维护现有功能。这是基本的职业行为。
如果有人需要历史信息,您的变更集应该与票证相关联。有一个理由列表,说明为什么事情是它们存储在每个文件中的方式。它存储在您的代码库外部 - 在您的源代码控制或其他一些存储库中。
根据我的经验,将票号放入代码通常是不良做法的症状。它表示偏离设计而不是固定设计。票号上写着“以前的代码是这样的,现在也是这样。” 代码库不应该反映它们自己的历史——重要的是它们现在如何工作。
对选项 1 的回应:为工单添加注释会降低代码的可读性。我认为(我的公司鼓励这样做)当您签入票修复时,您还应该更适当地记录该代码部分,但同样,添加票号可能只是令人困惑。
对选项 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
这使新代码默认可见,而旧代码隐藏。