A Question Of Structure
-
Like every other developer here I have a utility class(es) that hold these little tools. Caveat, make sure you document the utilities REALLY well, not just what you are doing but why you are doing it. I have the sinking feeling I get when ratting through a utility folder/class and wondering why the hell I would write such a thing. Also keep you utilities in smaller classes, string, date function, treeview etc all should have their own class, don't shove them into one humongous Utilities.cs
Never underestimate the power of human stupidity RAH
Rats. You're on to me. I created a code file called Utilities.cs, added the project's namespace, then added a static class called Utilities. VS bitched and moaned about it without the class declaration, and was quite vexed with me when I tried to include it in the Form file with a
usingstatement. My bad. Anyway, I'll take your advice to heart, and make more classes if I need other types of functions. For now, I only have the one function, which just strips the quotation marks out of a string variable. That was only necessary because the data source I have quotes every value, including empty ones, then separates them with commas. String.Split() doesn't like that very much, but it works perfectly after I clean the string. Since my source data is all in csv form, I expect that any other functions I need will be related to text handling and belong in the same class, but who knows where this will take me. I still don't know what I want the program to do, just that I know that these daily emails of csv data are doing me no good at all. Once I get them sorted out and stored in SQL Server, I'll figure out what else I want to do with the stuff. Talk about 'agile' programming... sheesh!Will Rogers never met me.
-
Stuffing these things into Program.cs would be an unusual practice. ;) If the driving reason is too much code in main form file, you might consider leaving the actual GUI stuff there (button click handlers, load event handler, closing event handler, etc) and moving the other functions to another file. It could be another "partial class" of the main form (probably another unusual practice) or a new class of helper functions as your suggested. It really depends on your design and needs. I predict that will be a concensus: it's up to you.
BDF I often make very large prints from unexposed film, and every one of them turns out to be a picture of myself as I once dreamed I would be. -- BillWoodruff
Big Daddy Farang wrote:
Stuffing these things into Program.cs would be an unusual practice.
Yes, but it's nearly empty, and I hate wasting space. :-D
Will Rogers never met me.
-
Such library routines I put in their own files. I can then make a Library DLL from them or include them individually as necessary. If you need it in this project, you'll need it in another. A stitch in time saves nine.
PIEBALDconsult wrote:
If you need it in this project, you'll need it in another.
Maybe. It typically takes me several years to complete a project. I get an idea for something useful. I spend four days (nights, actually) developing the framework. I get busy with other things, like work, and don't have time to touch the project. Months pass, then I have a chance to get back to it, but I've forgotten much of what I did and why. In the meantime, Microsoft has released a new buzzword into the wild, and my way of approaching the problem no longer fits, so I have to start over. A few days later I get busy again. And the cycle repeats. That's why I'm always a beginner, and ask the same questions over and over again... :sigh:
Will Rogers never met me.
-
If you just want to store them in a convenient location where you can get to them later on, if you need them, then you could always store them in an online snippet store. If you look at my article history, you'll find details of just such a one. If you want to store them in a convenient location for use in the project, I tend to have a little Utility class that I use.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
I don't plan to reuse them, I just want them out of my sight when I'm trying to figure out what my Form is doing. I find it handy to debug them in the Form, but once they work, I don't want to look at them anymore. I created a Utilities class in a separate file tonight, then cut and pasted the material from the Form to the Utilities file. That should work for now.
Will Rogers never met me.
-
If I'm not going to reuse stuff, then I usually leave it in the form code but make a lot of use of #regions. Group my UI stuff, BGW stuff, Logging, Helper methods, etc into seperate regions. Whatever makes sense. I then collapse all the regions and just look at the bits that interest me at the time.
I completely forgot about Regions, and that's a perfectly good use for them. We didn't need no stinkin' regions back when I was punching Hollerith cards for FORTRAN programs, and I forgot that we have that option. Still, it does seem kludgy to me to keep details like that in the main Form file. I like a nice, clean file that treats functions like well known old friends, to be called when convenient, but otherwise out of sight.
Will Rogers never met me.
-
Since I've done all my learning the hard way - buying lots of books and surfing CodeProject, most of the examples I see are short ones, meant to illustrate a concept. The usual routine is to fire up VS, create a new project, and do all the coding on one form. But that seems cluttered to me for a real program. I'm revisiting a project I started a while back, and it uses a main form for user interaction, but does a lot of background stuff that just clutters up the form code. For instance, one routine strips all the quotation marks out of a string so that I can later use the Split function to break up the fields in the string. It was convenient to debug it on the main form, but now that it works, it's just making the form code hard to follow. I don't have enough stuff to justify a library, but I'm wondering where it would be good to shove such things. Should I make a new class that contains all the helper functions? Or stuff these things in the nearly empty Program.cs file? Or something else? What's the usual practice?
Will Rogers never met me.
-
Rats. You're on to me. I created a code file called Utilities.cs, added the project's namespace, then added a static class called Utilities. VS bitched and moaned about it without the class declaration, and was quite vexed with me when I tried to include it in the Form file with a
usingstatement. My bad. Anyway, I'll take your advice to heart, and make more classes if I need other types of functions. For now, I only have the one function, which just strips the quotation marks out of a string variable. That was only necessary because the data source I have quotes every value, including empty ones, then separates them with commas. String.Split() doesn't like that very much, but it works perfectly after I clean the string. Since my source data is all in csv form, I expect that any other functions I need will be related to text handling and belong in the same class, but who knows where this will take me. I still don't know what I want the program to do, just that I know that these daily emails of csv data are doing me no good at all. Once I get them sorted out and stored in SQL Server, I'll figure out what else I want to do with the stuff. Talk about 'agile' programming... sheesh!Will Rogers never met me.
-
Roger Wright wrote:
make a new class
I usually create a "Utility" class that contains such functions.
Why is common sense not common? Never argue with an idiot. They will drag you down to their level where they are an expert. Sometimes it takes a lot of work to be lazy Please stand in front of my pistol, smile and wait for the flash - JSOP 2012
You beat me to it; I was going to suggest that. The second suggestion I was going to make is separation of the GUI code and the process code. I did a project where it seemed simplest at the time to put all the process code in the Form class. Predictably the Form class got cluttered (but adding #regions helped). I later realized having the Form class just send messages to a process class would have simplified it. Then I realized another benefit of separating the classes: Separating would have made adding a scripting capability much easier; just have the scripting class send messages to the process class (just like the GUI). Lesson: Separating functionality promotes simplicity (except when you pay for it with increased complexity from the communications between the classes).
"Microsoft -- Adding unnecessary complexity to your work since 1987!"
-
Great. Now you tell me, after I spent two days on this. ;P Well actually, a couple of dull hours at work with nothing more interesting to fill them. Don't tell the boss...
Will Rogers never met me.
-
Roger Wright wrote:
make a new class
I usually create a "Utility" class that contains such functions.
Why is common sense not common? Never argue with an idiot. They will drag you down to their level where they are an expert. Sometimes it takes a lot of work to be lazy Please stand in front of my pistol, smile and wait for the flash - JSOP 2012
While this is true, "Utility" class tend to morph into blob antipattern very quickly. Which is the problem he is now facing with the main form.
You can only be young once. But you can always be immature. - Dave Barry
-
While this is true, "Utility" class tend to morph into blob antipattern very quickly. Which is the problem he is now facing with the main form.
You can only be young once. But you can always be immature. - Dave Barry
Fortunately, I anticipated the problem and asked the question here. The answers are about what I expected, but I wanted the experience of more seasoned programmers before I cast off on a new course. At this point, I've got a Utilities file containing the one routine I've been discussing here, but there will be others. Just to avoid what you're describing, I plan to limit this file to text-related functions, and add more files if I need other types of helper functions, like database functions.
Will Rogers never met me.