home.cs 表单中的代码量是否存在限制或性能损失？
我正在 Visual Studio 2008 中用 C# 编写一个数据库应用程序前端。按顺序排列，我使用标签页方式更改显示给最终用户的信息，而不是使用新表单。
来自 VBA/MS Access，我记得如果您检查一定数量的代码行，它会产生错误并且无法编译。 C# 会在 Visual Studio 2008 中执行此操作，还是会影响性能？我知道代码可读性可能是个问题，因为一切都在一个地方，但我也可以将其视为在某些情况下的优势。
【问题讨论】：
标签： c# performance lines-of-code
在性能方面，您需要担心的不是 .cs 文件中的代码行，而是运行时表单上的控件数量可能会导致问题。如果只是几个选项卡上的几个控件，您将没有问题。如果在很多选项卡上有数百个控件，您可能会遇到性能问题（更不用说可用性问题 - 我个人讨厌具有多行选项卡的选项卡控件）。
另外，如果 UI 的目的更像是向导，您希望用户连续与所有选项卡交互，我认为选项卡不合适。选项卡旨在向用户呈现一组选项，而不要求他们一次查看所有选项。
最后，如果每个选项卡的用途明显不同，我发现将每个功能位封装为单独的表单会更容易。使用选项卡，您至少可以将每个位封装为用户控件，然后让表单上的每个选项卡托管一个用户控件的实例。
【讨论】：
我能预见的唯一问题是它在未来将很难维护。
尝试将主窗体的逻辑尽可能分解为类，这样当您需要添加某些内容时，您可以在不合适的情况下实际执行。
【讨论】：
如果您使用标签，您仍然可以创建自定义用户控件来保存标签中的内容。为每个选项卡制作一个控件，然后您可以将不同选项卡的代码分开。 MSDN 上有一个演练here。
作为对您上面关于不显示标签的评论的回应，我真的会重新考虑您是如何处理这个问题的。为什么不简单地将所有用户控件放在主窗体上，必要时在面板中，将它们全部设置为Dock = DockStyle.Fill，然后根据要显示的属性更改可见和启用属性？你可能会让自己变得比需要的更难。
对 cmets 的更多回复 - 您可能正在寻找类似 Java 中的 CardLayout 之类的东西。 GNU Classpath 版本的源代码可以在here 找到，它可能会给你一些关于如何实现它的想法。
【讨论】：
“我知道代码可读性可能是个问题，因为一切都在一个地方，但在某些情况下，我也可以将其视为优势。”
根据我的经验，这种态度最终会让任何必须在未来维护您的代码的人感到头疼，因为模块化代码是一种公认的做法，以便可能改变的部分或服务明显不同的部分目的是分开的。
话虽如此，我认为 VS 不会对文件长度施加限制，但我认为随着文件变长，尤其是在设计和代码视图。
我会敦促您保护未来的自己和他/她的理智，并将您的代码在逻辑上分解为单独的文件。以后你会感谢自己的！
【讨论】：
应该没问题。
请牢记良好的编码实践并模块化您的代码以提高可读性和可维护性。
另一方面，如果您在表单上放置了太多控件，则加载时间可能会更长。如果您想要一个简洁的界面，请将其纳入您的设计中。
【讨论】：
听起来很可怕，但我看不出它有什么问题。
【讨论】：
我的新工作继承了一个表格，它有超过 30,000 行。它是完全癌变的。在编码和模块化之前请三思！
【讨论】：