C# penalty for number of lines of code?

Question

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.

Answer 1

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.

Answer 2

Sounds horrible but I don't see any reason why it would be a problem.

Answer 3

I've never heard of such a limit. But if there is one, someone is sure to prove me wrong soon :)

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

"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!

Answer 8

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!