One of my classes, while fun and informative, comes with a side dish of WTF. The professor is a strong believer in all things Enterprise: Oracle, C#, and Java are the only things real programmers use. As part of the course, we are to create a simple database-backed application. When that was first announced to the class, I thought
OK, I'll make something web-based in Python(since that was what I'm doing for my real job). Things went by pretty well, until a few weeks into the course, after I'd already started on the Python implementation. The professor decided that all applications are to be done in C#, using Windows.Forms. I don't actually run Windows at home, so that was a bit of a problem. Luckily, I could code the main parts of the project in Mono, and convert it to a Visual Studio project at some later point. Fast forward to last week, when most of the students are apparently falling behind schedule. The professor, as a courtesy, gave us the source code to one of his own utility programs to base our projects on. Since this is on the Daily WTF, you know what's going to happen next:
His utility is broken into two parts - the user interface and back end. The interface is as you see above, and features among other things a 700 line method. Callbacks for the various buttons and fields contain large amounts of code, much of which sends raw (unescaped) SQL directly to ADO.NET. Some of the code appears to be auto-generated by Visual Studio, but it looks like other parts have been hand-edited. I really hope the GUI was one of the auto-generated parts.
The back end consists of static data, which accumulate state between calls to perform actions, and static methods which accept Windows.Forms objects as arguments and fill them with data. There are also a few static data in another file named "global constants", all of which is global, none of which is constant. These are manipulated by the GUI in between calls to the back end. Error handling consists of printing an exception's stack trace to the console and continuing on with whatever. The only comments to be seen are lines of code commented out but still kept around.
The best part?
It doesn't work. Every time I try to run it, it crashes on start-up. And my only hope to get a passing grade in this class is to repair it by the end of the quarter.
As the last reply to the sidebar said:
yawn. As a frequent reader, my WTF tolerance is high.
If you want university incompetence, I could tell you stories............
Ignoring the obvious incompetence, I think this is an extremely valuable class to take. I'm sure you'll get much much more real-world experience from this class than any other ones.
Go familiarize yourself with "Enterprise" tools like .NET and Java. You'll find them everywhere.
Figure out how to make WinForms actually work right. You won't be able to avoid it over the next few years.
Get used to big, poorly written and bloated apps. You'll have to work on them one day.
Just see it as a learning experience and part of the curriculum even if it just happens to be accidental
And when exactly did C#/.NET become 'enterprise', anyway? There's plenty of non-enterprise Java, for that matter.-cw
I thought VB, Access, and PHP were the Enterprise favorites. That's where we get our best WTFs. (register_globals FTW)
My current job (working on an internal web-based bug-tracking tool) is loaded with tons of WTFs and spending a good portion of my time tracking backwards through 6 or so PHP pages just looking for where the variables get created. Just because register_globals was set on by default in old PHP versions doesn't mean the programmer needs to use them. I wish I could just press a button and zap the creaters of this monolith every time I had to deal with a register_globals issue....
Don't cloud the issue (and your mind!) by spending time with the teacher's code-- especially since it doesn't work. You've already told us that it's poorly designed. The way you describe it, he did the program completely from within the Visual Studio Forms designer.
Oh, I absolutely abhor the Forms designer in Visual Studio for anything more than paper doll prototyping. Almost every form I've ever done has been a collection of repeated functionality, so I end up creating all my forms by hand-- building my own repeated blocks (ususally based on the GroupBox class) and placing them programmatically on the form (I admit it-- I have old-school ints in my Form class that act as vertical and horizontal layout cursors that are modified by the Width and Height properties of Control as it's added to the Form).
I've not played with Mono lately, but it was my experience that the Portable.NET implementation of System.Windows.Forms worked much better.
I also would still advocate for a seperation between the GUI and the application logic. You can debug the application from the command line in Mono or P.NET, and then add the GUI front end later (either way you do it-- Visual Studio forms designer or by hand)