>Refactoring XSL Content Assistance

>

Refactoring
“Enhancing or improving the quality of code in a program. Refactoring does not alter the functionality of the software; but, it makes it more maintainable for future changes. “

I’m slowly working on fixing some design and usability issues with the XSL Tooling’s content assistance. Many of the mistakes early on came from not completely understanding what I was doing. In such cases, one tends to write more code than is absolutely necessary and thus you can get a really ugly mess on your hands. So as I was reviewing the problem, I first decided to clean up what I had to make it easier to work with and modify going forward.

It’s taken me several days to clean it up (about five work hours), but as I worked I made sure I had some unit tests to make sure I wasn’t breaking any existing functionality with the changes I was making. In my case, I need to make sure that I was getting content assistance at the same spots as before, and that I was getting the same types of content assistance. As I refactored the code, I re-ran the tests. One thing I think needs to be improved in eclipse, is the speed in which the test applications launch to run the Plugin-Tests. Regardless, having the tests saved me more than once. As I refactored, if a test failed, I knew it was the code that I just changed recently so was able to fix it fairly quickly.

By the time I was done, I managed to cut the main XSL Content Assist Processor class down by 100 lines of code, and eliminated about 5 classes that I didn’t need to have or call. Some of the complex if-then-else logic has been replaced with more descriptive methods, and several extraneous local variables were eliminated as well. I also moved the XPath Content Assistance specific functionality out of the XSL UI and into it’s own XPath UI plugin to help better arrange the features. This didn’t add another dependency, as the XSL UI was already dependant on the XPath UI for some additional functionality we added earlier anyway.

One thing I have noticed is that because of some package scoping, there is a tendency for eclipse projects that want to reuse specific classes to have to copy those classes into their own plugins. I find package scoping to be of limited use when one is designing a API framework for adopters to possibly use. By not making it accesible to any other package, and particularly when dealing with plugins, it makes it much harder to reuse those classes. There may be valid reasons to package scope a class, but I tend to leave it to the users to tell me how they want to use it instead of me telling them.

Anyways, I think eclipse in general could use another round of refactoring where possible. Anything we can do to help reduce the memory consumption and overall size of eclipse for our users is something worth doing. Many of our users are still running single core systems, so every little bit helps.