C# 概述。 大括号或区域
我正在维护一个大型 asp.net 应用程序。
我的目标是确定针对特定票证添加的线路。 虽然可以使用我们的 SVN，但我想将其放入代码中。 因为对于第一次阅读代码的人来说，这些更改看起来很奇怪。
那么哪种概述方法更适合此目的
{
//response to ticket #xxxxx
...
...
..
}
或者
#region response to ticket xxxxx
..
...
..
#endregion
或者还有其他更适合此目的的方法
I am maintaining a large asp.net app.
My objective is to identify the lines added in response to particular tickets. While it is possible using our SVN, I want to put it in the code. because these changes would look just odd to a first time reader of the code.
So which outlining method is more suitable for this purpose
{
//response to ticket #xxxxx
...
...
..
}
OR
#region response to ticket xxxxx
..
...
..
#endregion
Or is there any other method more suited for this
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
尝试一些，看看你的同事的想法。
对于除了更琐碎的更改之外的任何事情，您最有可能将更改分散在源中 - 因此使用 SVN 责任/注释将是最好的选择。
Try a few and see what your colleagues think.
For anything but the more trivial changes you're most likely to have alterations scattered through your source -- so using SVN blame / annotate is going to be the best bet.
我们使用 SVN 的 JIRA 插件来直接查看特定工单修改了哪些代码文件。
区域可能会变得很麻烦，因为可能会出现使用一行代码来修复两张票的情况。 所以，选择第一个 //ticket #
We use JIRA plug-in for SVN to directly see what code files have been modified for a particular ticket.
Regions might become cumbersome as ther could be a case where one line of code is used to fix two tickets. So, pick the first one //ticket #
第一个选项。 “//对工单#xxxxx的响应”
你第一次这样做...
为此...
如果你决定使用#region范例，你会讨厌你的生活。 一/两行代码修复是常态，而且我从经验中知道，过度使用区域会不必要地隐藏数据，从而扰乱您的视觉流程。
最好这样做是为了隐藏您知道是垃圾的项目。
默认情况下，新代码可见，而旧代码隐藏。
The first option. "//response to ticket #xxxxx"
The first time you do this...
To this...
You will hate your life if you decide on a #region paradigm. One/two line code fixes are the norm, and I know from experience that overuse of regions messes with your visual flow by hiding data unnecessarily.
It would be better to do this to hide the items you KNOW are crap.
This leave the new code visible by default, and the old code hidden.
在两者之间，一定要使用注释——它们非常灵活。 区域对于此类事情没有好处 - 如果多个票证需要重叠的代码更改怎么办？ 这在较长的评论中很容易解释。
但是，无论如何，我反对将此类信息放入评论中。 实际上，没有人会偶然发现一年前编写的代码并去查找票证。 代码应该是不言自明的，在非常奇怪的情况下，注释应该描述代码实际做什么，而不是为什么。 为了解决新读者的具体问题 - 您的同事不需要解释为什么代码是这样的。 他们会假设是这样是有原因的，并且在进行其他更改时将始终尝试维护现有功能。 这是基本的职业行为。
您的变更集应与票号相关联，以防有人需要历史信息。 对于每个文件中的存储方式，有一系列理由说明。 它存储在您的代码库外部 - 无论是在您的源代码管理还是其他存储库中。
根据我的经验，将票号放入代码中通常是不良做法的症状。 它表示偏离设计而不是修复设计。 票号显示“这就是代码以前的样子，这就是现在的样子。” 代码库不应该反映它们自己的历史 - 重要的是它们现在如何工作。
Between the two, definitely use comments - they are very flexible. Regions are no good for this sort of thing - what if multiple tickets require code changes which overlap? That's easily explained in a longer comment.
However, I'd argue against putting this kind of info in the comments anyway. No one is actually going to stumble onto code written a year ago and go look up the ticket. Code should be self-explanatory, and in the very odd case where it is not, comments should describe what the code actually does, not why. To address your specific concern of new readers - your colleagues do not need justification for why code is the way it is. They will assume it is that way for a reason, and when making additional changes will always try to maintain the existing functionality. That's basic professional behavior.
Your changeset should be associated with the ticket # in case anyone needs historical information. There's a list of justifications for why things are they way they are stored on each file. That is stored external to your codebase - either in your source control or some other repository.
In my experience, putting ticket numbers in the code is usually a symptom of bad practices. It denotes a deviation from the design instead of fixing the design. A ticket number says "this is how the code was, and this is how it is now." Codebases should not reflect their own history - all that matters is how they work right now.
对选项 1 的回应：添加票证注释会降低代码的可读性。 我认为（我的公司鼓励这样做），当您签入票证修复时，您还应该更适当地记录该代码部分，但同样，添加票证号可能会令人困惑。
对选项 2 的回应：区域用于将具有相似目的的功能分组在一起，因此我也不推荐此选项。
建议的选项：使用注释函数的 /// 标准并添加“This is What was Changed”。 元素。 这种方式修复不会破坏正常的可读性，但可以很容易地看到与票证相关的功能。 作为一个额外的好处，这个机制是自我记录的，所以这些会自动放入您生成的文档中。 注意：您可能需要检查是否支持自定义标签。
Response to Option 1: Adding comments for tickets would decrease the readability of code. I think (and this is encouraged at my company) that when you check in a ticket-fix, you should also document that section of code more appropriately, but again, adding a ticket number might just be confusing.
Response to Option 2: Regions are for grouping functions with similar purpose together, so I would not recommend this option either.
Proposed Option: Use the /// standard of commenting functions and add a This is what was changed. element. This way fixes don't disrupt the normal readability, but it's simple to see functions that were involved with tickets. As an added bonus, this mechanism is self-documenting, so these would automatically get put into your generated documents. Note: You might want to check that custom tags are supported.