Code generated for swing always fails when it comes to code quality. Inevitably, there's one method that builds the entire interface, and there's anonymous event handling code that calls member methods.
Does anyone have some nuggets on transforming this monstrous code to well organized code.
Is it worth going without a GUI builder tool, for the sake of code quality.
Thanks
The answer to your question lies in how much this code is going to be maintained, and how central it is in your module.
If this is a low-maintenance side component which its quality suffices for most needs, I see no point in refactoring code which works now, and can easily be thrown away and replaced by something new in the future (given it is a side component). Given the fact the Swing/AWT code is generally not nice to look at, you might be able to pass this one by.
However, if you are going to be working on this code in the long run, and it is central in your architecture, the time spent on refactoring is going to be worth it when it comes to maintainability and supportability in the future.
Generally, you shouldn't be hand-editing generated code.
If you use an editor with code-folding, I suggest using that to keep the rest of the code looking tidy.
If you will keep using the GUI builder, then there's not much point to refactoring any output of the GUI builder. Depending on the specific builder, any refactoring you do to its code may mean that you can no longer use the builder on that GUI. Yes, GUI builders often generate ugly code. But as long as you will continue to use the GUI builder, just set findbugs and checkstyle, etc, to ignore the file(s) created by the GUI builder and move on.
I have personally done this both ways. In some cases, I've abandoned the GUI builder. For these, I ended up refactoring the code to make it more maintainable.
A lot of code generation systems have a model in which they generate two classes for everything (let's say a screen): one which they are free to revise at will and a second, a subclass of the first, which you the developer are free to revise at will (they will only generate the subclass once). If your system is doing this, then I would say it makes sense to clean up the subclass - the one you'll be working on - and leave the superclass alone (because of course any work you put into cleaning it will be wiped out the next time you invoke the generator).
My approach is to avoid code generation. Bad formatting is the least of your worries.
It's not too hard to build a GUI with straight Swing if you get to know a few layouts (border and flow at a minimum), and you can also create routines to automatically generate your GUI based on your data or metadata--a nice trick that a GUI builder cannot even start to do (but if you're using a GUI builder, you'll probably never even try to make it data driven).
Personally I'd like to see more builders that generate a "Class" file instead of a "Java" file--something with nothing but controls laid out in a reasonable manner, allowing you to access the controls remotely either through a getter or something. (Heck, since it's such a specific use case, I wouldn't even have a problem making the members public..).
Objective-C does something like this, it's only the second builder I've seen that doesn't try to use code generation (the first was a private one we built for a product I worked on a long time ago that never got very far)
I would avoid a GUI builder as much as possible. Firstly it creates ugly code that generally can't be refactored (good luck trying to get your GUI builder to parse refactored code).
But more importantly, using a GUI builder really hampers re-usability. Like anything, if you're smart you can use OOP to your advantage. Create re-usable components. Re-usable behaviours. If you're application is even mildly complex, you'll want to use a framework to make things more manageable. If you don't, good luck changing things in the future. You'll probably be ok for one, maybe two version, but after that you'll be fighting hard to get anything done. Every change will have to be done in a million places.
Plus you can learn Swing pretty fast. It's not that hard once you get the hang of it. Using proper OO design in your Swing code will make a world of difference for the future.