如何更改太大的文件（收到 StyleCop 的警告）？
我收到 StyleCop 关于我的文件的警告。
警告 1 CR0005：该文件非常长，有 508 行。请考虑重构，使其不超过 500 行。
警告 2 CR0002：方法太长。它有 58 行长。考虑重构以使其不超过 50 行。
你们如何更改代码？这方面的最佳实践是什么？我不知道将我的代码分成更小的代码 - 害怕让我的代码变得如此复杂。
所以，请大家帮忙^_^！
南。
I am recieving warning about my file by StyleCop.
Warning 1 CR0005: The file is very long at 508 lines. Please consider refactoring to make it 500 or fewer lines.
Warning 2 CR0002: Method is too long. It is 58 lines long. Consider refactoring to make it 50 or fewer lines.
How are you guys making changes to your codes? What are the best practices for this? I have no idea to divide my codes to smaller ones - being afraid of making my codes become so-complex.
So, please help ^_^ !
Nam.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
您应该阅读 Martin Fowler 的书“重构：改进现有代码的设计”和 Danijel Arsenovski 的“C# 和 ASP.NET 中的专业重构”。
You should read Martin's Fowler book "Refactoring: Improving the Design of Existing Code" and "Professional Refactoring in C# & ASP.NET" of Danijel Arsenovski.
班级尝试做得太多吗？是否可以将其分为多个更小的类别，每个类别都有更具体和更好定义的目的？如果是这样，请将其重构为多个类。
是否可以将方法中的一些代码提取到它自己的方法中以使其更易于理解？如果是这样，就这样做。
上述任何一个更改都会使代码更难以理解吗？如果是这样，请忽略 StyleCop。请记住，它只是一个通用工具，可以帮助您的代码更易于阅读。几乎可以肯定，至少有一些建议对您的情况没有意义。
Does the class try do to much? Could it be split into multiple smaller classes that each had a more specific and better defined purposes? If so, refactor it into multiple classes.
Could some code from the method be extracted out into it's own method to make it easier to understand? If so, do so.
Would either of the changes above make the code more difficult to understand? If so, ignore StyleCop. Remember, it's just a generic tool to help make your code easier to read. There will almost certainly be at least some recommendations that won't make sense for your circumstances.
我会抑制警告并担心更重要的事情。
我不确定对文件或方法的大小施加如此任意的限制是否有意义。这与数字 50 和 50 无关。 500 本身，但事实上有这样的数字。它从哪里来？为什么 50 行被认为可读，而 58 行则不然？
正如此处所示，专注于这些指标可能会适得其反，并分散人们对实际问题的注意力。也许时间可以更好地花，并且更好地服务于良好的设计原则，例如确保适当的关注点分离之类的事情。根据逻辑上应包含的内容来拆分行和方法，而不是将它们分解以满足任意大小标准。
I'd suppress the warnings and worry about more important things.
I'm not sure it makes sense to impose such an arbitrary limit on the size of a file or method. It's not so much the numbers 50 & 500 themselves, but the fact that there is such a number. Where does it come from? Why is 50 lines considered readable, but 58 isn't?
As demonstrated here, concentrating on these metrics can be counter productive, and draw attention away from real issues. Perhaps time might be better spent, and good design principles better served, ensuring something like proper separation of concerns, for example. Split your lines and methods according to what should logically go in them, rather than breaking them up to meet arbitrary size criteria.
好吧，“提取方法”重构对于缩短方法（通过将它们放入另一个方法中）非常有用，我相信这是在 2010 年。（突出显示一些代码，右键单击，它应该在菜单中的某个位置）。
分解文件的最佳方法（假设其中只有一个类）是将某些功能提取到另一个类中。谷歌“Extract Class”，您会找到一些相关信息。
就像@Justin所说，这样做一开始可能看起来更复杂，因为有更多的文件/方法需要处理，但因为每个文件/方法更小，所以一次需要处理的东西更少。有些（受人尊敬的）人真的接受了这一点远。这需要一点时间来适应，但你的代码（可以说）会更好。
Well, the 'Extract Method' refactoring is very useful for making methods shorter (by putting them into another method), which I believe is in 2010. (Highlight some code, right click and it should be in the menu somewhere).
The best way to break a file up (assuming you only have one class in it) is to extract some of the functionality into another class. Google 'Extract Class' and you'll find some info on it.
Like @Justin says, doing this might seem more complex at first because there are more files/methods to deal with, but because each file/method is smaller, there's less to deal with at any one time. Some (respected) people take this really far. It takes a little getting used to but you code will be (arguably) better for it.
其他人提到了重构，并且还专注于分解类以仅执行 1x 职责（OOP SOLID 规则的一部分）。然而;如果你的类仍然有 500 行代码，并且履行一项职责，那么你的处境并不算太糟糕。
如果您的代码文件包含 XML 文档和空格，那么 500x 行只是稍微大一点（这取决于它的作用）。我的许多“简单”课程完成后大约有 350 行。越小越好，但简洁才是您真正想要的。
另一本了解代码外观的好书是 Robert C. Martin 的《简洁代码》。它为设计经过深思熟虑的类和方法制定了许多好的规则。
Others have mentioned refactoring, and also focusing on breaking the class down to do just 1x responsibility (part of the S.O.L.I.D. rules for OOP). However; if your class is still 500x lines, and performing one responsibility, then you're not in too terrible a position.
If your code-file contains XML documentation and white-spaces, then 500x lines is only slightly large (and that's dependent on what it does). Many of my "simple" classes end up around 350 lines once completed. Smaller is better, but concise is really what you want.
Another good book for understanding how your code should look is Robert C. Martin's Clean Code. It lays down many good rules in designing well thought-out classes and methods.
可以将类、结构或接口的定义拆分为两个或多个源文件。每个源文件都包含类定义的一部分，并且在编译应用程序时将组合所有部分。例如，此处“bar”类分为 foo1.cs 和 foo2.cs。
foo1.cs
foo2.cs
有关详细信息，请参阅 部分类定义（C# 编程指南）
It is possible to split the definition of a class or a struct, or an interface over two or more source files. Each source file contains a section of the class definition, and all parts are combined when the application is compiled. For example here the 'bar' class is split between foo1.cs and foo2.cs.
foo1.cs
foo2.cs
For more information on this see Partial Class Definitions (C# Programming Guide)
这不是 StyleCop 附带的规则。这是你们公司内部开发的东西吗？我很好奇该规则背后的理由。 500 行似乎是一个相当严格的限制。
This is not a rule that ships with StyleCop. Is it something your company developed in house? I'm curious about the rationale behind the rule. 500 lines seems like a pretty strict limitation.