Structuring Windows Forms apps... [modified]

[1 21 Gigawatts]

Hey thanks Luc, it's nice to know how others do it. :thumbsup:

"If you can't explain it simply, you don't understand it well enough" ~ Albert Einstein "If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." ~ Paul Neal "Red" Adair Now reading: 'The Third Reich', by Michael Burleigh

[Luc Pattyn]

you're welcome. :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

---

I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages

---

[vtchris peterson]

It's good that you're thinking about this now while your code base is small :) I find that Windows Forms code is pretty easy to keep tidy. If you feel like a given class is getting untidy, it's probably time to decompose it into simpler components. That said, don't over-decompose to start with as this creates unnecessary levels of indirection. Defer refactoring until it makes sense (e.g. if you want to re-use common functionality in multiple places). The best tip I can give is to be rigorous about namespace organization and use meaningful type names so that someone else (or you 6 months from now) can know where to start looking.

[Roger Wright]

Say, Luc, I have a related question, since you've been helpful on project I've been working on. When you are dealing with classes that represent real world objects that need to be handled in similar ways, do you define them in a separate file, or just inline where you need them? For example, the project I'm working on is intended to manage about 6 types of devices used in electrical substations. I'm only working on one type right now, because the techniques that work there will work for the others. I've defined the one type in the main program form, but I'm thinking it will be more convenient later to create a library file containing all of the devices and 'using' it whenever I need to later as the program develops. I really prefer to keep everything in one file (from past history with procedural programming) because it's easier to follow the program flow. But I can already see that this approach will be a nightmare with a Windows program if it grows beyond a few thousand lines. And it will...

"A Journey of a Thousand Rest Stops Begins with a Single Movement"

[1 21 Gigawatts]

I think you've gone along the same lines as Luc (above) so that's another vote for decomposing. I'll have a look though the code and see where I can best split it up. Many thanks :thumbsup:

"If you can't explain it simply, you don't understand it well enough" ~ Albert Einstein "If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." ~ Paul Neal "Red" Adair Now reading: 'The Third Reich', by Michael Burleigh

[Luc Pattyn]

Hi Roger, I don't have any strict rules for this; I don't start a new file for every new class (or type) I create; however I try and keep most files at less than 500 lines of code, using either separate classes, or partial classes, or inheritance as outlined before. :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

---

I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages

---

[Roger Wright]

Thanks, Luc! :-D I moved the Recloser class to its own file and namespace, then modified the rest of the project to 'use' my new namespace. That file will grow, adding new equipment types as I expand the app, and defining them on the fly, wherever I happen to need them is going to get really ugly. This is much better, though it was a scary moment there when I commented out my original class definition on the main page and clicked Build Solution. It worked very well, much to my surprise.

"A Journey of a Thousand Rest Stops Begins with a Single Movement"

[Ashfield]

These might help (or drive you mad as they do me!) StyleCop and FXCop - they are both free AFAIK

Bob Ashfield Consultants Ltd Proud to be a 2009 Code Project MVP

[vtchris peterson]

Oh man, FXCop... that brings back (painful) memories.... I used it about 6 years ago on a team with lots of junior developers (and senior developers who thought they were above adhering to conventions). It was effective, but comes with a lot of overhead. On a team of competent developers, I much prefer a document describing the style convention rather than a tool that enforces it. Come to think of it, I prefer teams of competent developers outright :)

[Ashfield]

I didn't say I would use it through choice :) Like you say though, for juniors in particular it can stop some bad habits (and introduce some different ones :laugh: ), so I thought it may be of interest to the OP

Bob Ashfield Consultants Ltd Proud to be a 2009 Code Project MVP