Twitter github

‘Tis the Season to Refactor

I like the beginning of new releases because it gives you time to reflect on things you couldn’t do during the crazy end game days. One of those things you couldn’t really do was refactor. I like refactoring for multiple reasons…

  • It allows you to clean up code and strive for simplicity
  • Sometimes allows you to further modularize your code
  • You find instances of code that shouldn’t be referencing certain things
  • It has a side effect of possibly bringing on new contributors…
  • and so on…

I don’t like refactoring for multiple reasons…

  • refactoring a bunch of packages when all your NLS strings are in one sucks
  • refactoring a bunch of packages when dealing with a central image registry sucks

I’m excited to see that already for 3.5M1, we will have a couple refactorings in the Eclipse SDK:

[207704] – Decouple from UI

This is exciting because it now allows people to take advantage of the core Compare code without dragging in the UI. In the past, the core and UI code were all in one plug-in ( This wasn’t good for people who wanted to run compare code headlessly and also people that just wanted to take advantage of the ability to diff things in another context.

Thank you Compare team for making this happen!

[241145] – [refactoring] move UA code into separate plug-ins

On the PDE side of things, I finally decided to refactor out the User Assistance (UA) tooling into separate plug-ins. I did this for two selfish reasons… (1) the PDE core and ui plug-ins were getting big… (2) I wanted to bring on another contributor to PDE to help maintain and grow the user assistance tooling in Eclipse. I don’t think there’s anything wrong with that ;)?

Anyways, I highly recommend people to look now and reflect on what they can possibly refactor out for the benefit for the wider Eclipse community. For the eclipse community, it’s a good time to bug Eclipse developers to refactor things that you always wanted… or better yet… provide patches to move things along quicker.