Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a large (at least for me - approximately 10k lines) project that is written in C#. I have a treeview object on the left of my form and i have many nodes on my treeview. When i click a node, i bring up a panel on the right side of form. Since i only do GUI item operations (filling textboxes, clicking buttons, showing images on pictureboxes etc.), i write all of my code into MainForm class. This seems not very good but on the other side, i think i have to write into MainForm class because all of my job is to evaluate form items on panels. What should i do to write a more portable or understandable code? Do i have to write into MainForm class or do i have some options or methods to implement?

share|improve this question
up vote 7 down vote accepted

GUI classes can quickly grow into a ball of mud if they're not managed carefully. Simple refactoring will do the trick. Some tips:

  1. Push everything that's not directly related to the GUI into separate classes.
  2. Refactor as much of the remaining code as possible out of the event handlers into their own methods.
  3. Use #regions to separate the event handlers from the rest of the code, and to break the rest of the code into functional areas.
  4. Encapsulate customized behavior by subclassing controls.
share|improve this answer
+1, even w/ the mentions of #regoins. :P. I Completely agree w/ 1, 2 and 3. – DevSolo Jun 14 '12 at 20:36
Yeah, code-folding is not everyone's cup of tea, but sometimes you don't have anything better. – Robert Harvey Jun 14 '12 at 20:39
Like all things, it's not an absolute avoidance of course. When I see need for regions in my code, I consider refactoring the 'region' out into it's own class. – DevSolo Jun 14 '12 at 20:49
I would add, 5. Keep code in event handlers to a minimum. It's easy to violate the DRY principal w/ code duplication in them. – DevSolo Jun 14 '12 at 20:52
@DevSolo I think it's too easy to jump on the #region hate-wagon. I don't see anything wrong with using them to neatly group a well-refactored 100 line class - it's still easier to scan the result. I really don't want the first screen worth of lines on every class to be the copyright notice and using declarations. Just don't use them as an excuse to hide bad / badly structured code. I think it's the same thing you are saying, but I felt it needed to be pointed out. – Daniel B Jun 15 '12 at 6:27

That kind of code would be much easier to handle if, for example, instead of having all the customizing behavior of a treeview in your MainForm, you actually had a class that extended TreeView and made all of the customization there, and your MainForm just used it.

You should do that for every control that exists in your window (or canvas).

share|improve this answer

This is something that you will only learn by writing more and more code. A 10k line file is gigantic, and you probably have a lot of code that can be split out. The problem is that if you didn't initially approach the problem with plans to separate concerns, things may be so intermingled now that it would require essentially an entire rewrite.

That said, at 10k lines, is the program "complete"? Or is someone going to be maintaining this? If this was a small one off utility, then you might be best off to leave as is. On the other hand, if this is something you need to maintain, you will likely benefit from intense refactoring.

Not knowing your domain makes this difficult, but here are some common forms patterns that might be applicable:

  • separate the data layer
  • decompose the form into UserControls to contain pieces of it
  • create service classes that act as helpers to encapsulate computations
share|improve this answer

I guess you do not have only GUI operations (or at least not only operations that must be programmed in this way): your treeview shows some data, and in your panels you have also a lot of data. You may have used (or abused) just GUI items as containers for this, but that's not the way things must (or should) be organized. I suggest start separating the GUI-dependent parts from the data. Then you will most probably identify GUI-independent operations which you can separate from your main form.

share|improve this answer
Since i only do GUI item operations (filling textboxes, clicking buttons, showing images on pictureboxes etc.) -- OP – Yam Marcovic Jun 14 '12 at 20:52
@YamMarcovic: that's the statement I was referring to. I guess the OP believes he has only GUI item operations - but in fact since he has a 10K program, I guess the thing does something with a meaning behind the GUI operations. – Doc Brown Jun 14 '12 at 21:10
I realize that, but my point was that your answer, however true it could be, bluntly disregards the real question. It's not up to us to "guess" his intentions when he explicitly states he's aware of what he would have otherwise expected us to tell him (which also hints that he's familiar with your kind of advice). Wouldn't you agree? – Yam Marcovic Jun 14 '12 at 21:19
@YamMarcovic: my answer was intended just to be a suggestion to the OP to rethink his perspective. To my experience, people having problems to get a better structure into their programs often make false assumption like "it is all GUI, so I cannot separate parts into different layers". – Doc Brown Jun 15 '12 at 17:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.