C# 对代码行数的惩罚？
我的 home.cs 表单内的代码量是否有限制或性能损失？
我正在 Visual Studio 2008 中用 C# 编写一个数据库应用程序前端。按照排列方式，我使用选项卡页方式更改向最终用户显示的信息，而不是使用新表单。
我来自 VBA/MS Access，我记得如果您超过一定数量的代码行，就会产生错误并且无法编译。 C# 会在 Visual Studio 2008 中执行此操作吗？或者我会遭受性能损失吗？ 我知道代码可读性可能是一个问题，因为所有内容都集中在一个地方，但我也可以将其视为在某些情况下的优势。
Are there limits or performance penalties on the amount of code inside of my home.cs form?
I am writing a database application front-end in C# in Visual Studio 2008. The way things are lining up, I am using a tab-page way of changing the info shown to the end users, instead of using new forms.
Coming from VBA/MS Access, I remember that if you go over a certain number of lines of code, it would produce an error and not compile. Will C# do this in Visual Studio 2008, or will I suffer a performance hit? I know code readability could be a problem because everything would be in one place, but I can also see that as an advantage in some situations.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
在性能方面，您需要担心的不是 .cs 文件中的代码行 - 运行时窗体上的控件数量可能会导致问题。 如果只是几个选项卡上的几个控件，那么您不会有任何问题。 如果大量选项卡上有数百个控件，则可能会遇到性能问题（更不用说可用性问题 - 我个人讨厌具有多于一行选项卡的选项卡控件）。
另外，如果 UI 的目的更像是向导（您希望用户连续与所有选项卡进行交互），我认为选项卡并不合适。 选项卡旨在向用户呈现一组选项，而不要求他们立即查看所有选项。
最后，如果每个选项卡的用途明显不同，我发现将每个功能封装为单独的表单会更容易。 使用选项卡，您至少可以将每一位封装为用户控件，然后让表单上的每个选项卡托管一个用户控件实例。
It's not the lines of code in your .cs files that you need to be worried about with regards to performance - it's the number of controls on your form at runtime that might cause problems. If it's just a few controls on a few tabs, you will have no problems. If it's hundreds of controls on lots of tabs, you may have performance problems (not to mention usability problems - I personally hate tab controls with more than one row of tabs).
Also, I don't think tabs are appropriate if the purpose of the UI is more wizard-like where you want the user to interact with all of the tabs in succession. Tabs are meant for presenting sets of options to the user, without requiring them to see all the options at once.
Finally, if the purpose of each tab is significantly different, I find that it's easier to encapsulate each bit of functionality as a separate form. With tabs, you could at least encapsulate each bit as usercontrols, and then have each tab on your form host one instance of a usercontrol.
我预见到的唯一问题是将来它将很难维护。
尝试将主表单的逻辑尽可能地分解为类，以便当您需要添加某些内容时，您实际上可以在不合适的情况下完成它。
The only problem i would foresee is that in the future its going to be very hard to maintain.
Try break the logic of that main form up as much as possible into classes so that when you need add something you can actually do it without having a fit.
如果您使用选项卡，您仍然可以创建自定义用户控件来保存选项卡中的内容。 每个选项卡创建一个控件，然后您可以将不同选项卡的代码分开。 MSDN 上有一个演练此处 。
为了回应您上面关于不显示选项卡的评论，我真的会重新考虑您的处理方式。 为什么不简单地将所有用户控件放在主窗体上，如有必要，放在面板中，将它们全部设置为
Dock = DockStyle.Fill，然后根据其更改 Visible 和 Enabled 属性你想展示一个吗？ 你可能会让自己变得比实际需要的更加困难。更多评论回复 - 您可能正在寻找类似 Java 中的 CardLayout 的东西。 GNU Classpath 版本的源代码可以在 这里，它可能会给您一些关于如何实现这一点的想法。
If you are using tabs, you can still create custom user controls that will hold the content that goes in the tabs. Make a control per tab, and then you can keep your code for the different tabs separate. There is a walk-through on MSDN here.
In response to your comment above, about not showing the tabs, I would really re-think how you're approaching this. Why not simply have all of your user controls sitting on your main form, in a Panel if necessary, have them all set to
Dock = DockStyle.Fill, and then change the Visible and Enabled properties based on which one you want to show? You may be making this harder on yourself than it needs to be.More responses to comments - You may be looking for something like the CardLayout in Java. The source for the GNU Classpath version can be found here, it might give you some ideas on how to implement this.
“我知道代码可读性可能是一个问题，因为所有内容都集中在一个地方，但我也认为在某些情况下这是一个优势。”
根据我的经验，这种态度最终会让任何将来必须维护代码的人感到非常头疼，因为模块化代码是一种公认的做法，以便将可能更改的部分或服务于明显不同目的的部分分开远离彼此。
话虽如此，我认为 VS 对文件的长度没有限制，但我认为随着文件变长，您会遇到一些严重令人沮丧的性能下降，特别是在设计和代码视图之间切换时。
我强烈建议您保存未来的自己和他/她的理智，并将您的代码逻辑地分解为单独的文件。 以后你会感谢自己的！
"I know code readability could be a problem because everything would be in one place, but I can also see that as an advantage in some situations."
In my experience, this attitude will ultimately leave anyone who has to maintain your code in the future with quite a headache, as it's an accepted practice to modularize your code so that the pieces that may change or the ones that serve distinctly different purposes are separated away from each other.
With that said, I don't think there is a limit imposed by VS on the length of your files, but I think you will run into some seriously frustrating performance degradation as your files become longer, especially while switching between design and code views.
I would urge you to save your future self and his/her sanity and break your code up logically into separate files. You'll thank yourself later!
这应该不是问题。
只需牢记良好的编码实践并将代码模块化以提高可读性和可维护性即可。
另一方面，如果您在表单上放置了太多控件，则加载时间可能会更长。 如果您想要一个活泼的界面，请将这一点纳入您的设计中。
It shouldn't be a problem.
Just keep good coding practices in mind and modularise your code for readability and maintainability.
On the other hand, if you put too many controls on your form, then it will probably take longer to load. Factor that into your design if you want a snappy interface.
听起来很可怕，但我看不出有任何理由会成为问题。
Sounds horrible but I don't see any reason why it would be a problem.
我有一个随着我的新工作继承的表单，它有超过 30,000 行。 它完全是癌性的。 请在编码和模块化之前三思！
I have a form that in inherited with my new job that had over 30,000 Lines. It is completely cancerous. Please think before you code and modularize!