• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Open Source Tool for Code Refactoring

 
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,
Is there any open-source tool avaialable for code Refactoring.I came through one at
this
what are the other tools available as open-source
 
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Refactoring tools
I'm sure you can check out for yourself which tools are open source/free (you probably want the latter ). Most of the plug-ins are free it seems.
BTW, why are you asking for refactoring tools without mentioning which IDE you use? You don't want to do your refactorings in a seperate app, do you?
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rishi Singh:
Hi All,
Is there any open-source tool avaialable for code Refactoring.I came through one at
this
what are the other tools available as open-source


Take a look at the "Refactoring Tools" section on http://www.refactoring.com/
 
Rishi Singh
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Zelle,
"BTW, why are you asking for refactoring tools without mentioning which IDE you use? You don't want to do your refactorings in a seperate app, do you? "
We have not yet reached the stage of refactoring as such in the present project.But very soon we have to as we get into optimization stage.The IDE which Iam using is EditPLus/TextPad , and I need to do refactoring with a these only, though we are thinking of using JBuilder or Rationale
 
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've had good luck with JRefactory, http://jrefactory.sourceforge.net/.
It integrates well with JBuilder and works well from the command line.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rishi Singh:
[QB]We have not yet reached the stage of refactoring as such in the present project.


There shouldn't be something like a 'refactoring stage' - it is best to refactor from the first day to the last.
As Ron Jeffries puts it: If you can say how much of your time you spent refactoring, you are doing too little of it...
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Originally posted by Rishi Singh:
We have not yet reached the stage of refactoring as such in the present project.But very soon we have to as we get into optimization stage.
Sorry, but to me this statement is a warning sign of difficulties and problems to come or that you equate refactoring with optimization, which it isn't.
Refactoring is best done consistently and throughout coding. It is also best done together with unit testing. The mantra goes something like "Code a little (test + code), make it work, refactor." The idea is that you never let your design get so bad and out of hand as to make it difficult if not impossible to do anything else but throw away huge chunks of work and start over again. You normally don't wait for the "optimization phase" to refactor.
Junilu
 
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Junilu Lacar:
Refactoring is best done consistently and throughout coding. It is also best done together with unit testing.


Again, I seem to be in the same boat an Junilu and Ilja. You shouldn't do your design work, blindly code it, and then move on. If your system has any sort of complexity in it (which even the smallest systems do), you're bound to find deficiencies in your design as you implement it. My usual goal is to implement a small part of the design, test it, and then refactor it and revisit the design to make it better. This approach helps keep the design (and therefore, the code) clean and will leave you with a higher quality system.
Corey
 
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

My usual goal is to implement a small part of the design, test it, and then refactor it and revisit the design to make it better. This approach helps keep the design (and therefore, the code) clean and will leave you with a higher quality system.


When you have plenty of time, sure you could do something like this. Refactoring is sure a on-going process. Write you code with the best possible maintainability as you can, apply the patterns only when it make senses (not because you know it, and not because you want to be a pattern-man ) Take the resources and deadline in mind.
Refactoring often comes in second stage of the programming and may or may not be your job.
 
Rishi Singh
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"Refactoring often comes in second stage of the programming and may or may not be your job"
Even I wanted to emphasize on the same aspect that as if of now we need to maintian the deadline and see to it that the work is completed on time, so the case of refactoring (i.e simultaneously spending time in making it work with less resources)has to come, well i definately can't wait to get my code in such a shape from where i can't refactor it.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
All I can say to that is "Cheap, fast, good. Pick two."
Well, maybe I have a little more to say... we always "try to maintain a deadline". After the fact though, can you really say that the deadline was realistic? Hardly ever. Saying that there's no time to refactor is like saying there's no time to make it good. So, if you get complaints about your work despite meeting the "deadline", you shouldn't be surprised. In the long run, you really end up wasting more time and money by not doing refactoring because of all the debugging and rework that you have to do.
 
Rishi Singh
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes Junilu,
You r rite, there is no point in maintaining deadline if u get complains about ur work later on, but this thing should be handled by the project manager.Iam just an analyst and for me getting the work done on time in of higher priority then giving them an optimal solution, they need to give us a time-frame where optimization can be done.
 
Frank Zheng
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just hope my boss know the important of refactoring and patterns. That would make my life easier.
 
Rishi Singh
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That's what frank they don't lay much importance to all these and offcourse it takes time to implement so u r in soup, both ways, well half the time iam in that condition in my office
 
Frank Zheng
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well don't get me wrong. What I mean by saying that refactoring comes in second stage in that you don't want to refactor everything just because you are good at refactoring. Over-refactoring may results adverse effect in certain circumstance (Anti-patterns).(Wise and stupid can be very close. )
 
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have two comments to add. First, I've used JRefactory and have found it easy to use and helpful. I recommend it to other developers.
WRT to when to refactor, I think you do need explicit refactoring stages. That is not to say, you should not "code a little, refactor a little." It's just that sometimes you're too close to a problem to see the full picture. Sometimes you just need to set aside a few days to explicitly review code and then refactor the discovered problems.
I think this si especially true during the final push before a release. Except for the very best to .1% of companies, I think all companies tend to get a little sloppy in the final push in the last few weeks of a project. It's often worth doing some explicit cleanup prior to stating the next version.
--Mark
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Junilu Lacar:
All I can say to that is "Cheap, fast, good. Pick two."


I disagree.
I like to think about not doing a necessary refactoring as taking on a "design debt". You are paying interest for this debt from the very first minute on until you decide to settle them.
Sloppy code will just slow you down - good and cheap will go hand in hand.
See http://c2.com/cgi/wiki?QualityElbow for some interesting additional thoughts.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mark Herschberg:
Except for the very best to .1% of companies, I think all companies tend to get a little sloppy in the final push in the last few weeks of a project. It's often worth doing some explicit cleanup prior to stating the next version.


Mhh, better than planning for a cleanup phase might be to plan for becoming one of those top companies. What do these companies do to not get "a little sloppy" in the final push?
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:

I disagree...
Sloppy code will just slow you down - good and cheap will go hand in hand.

Yes, good and cheap go hand in hand, in the long run. The problem is that most projects are managed with only the short-term in mind: Will doing this affect my meeting the immediate deadline? The justification for not doing refactoring is often because "we don't have the resources (time/money/people) to do it." This kind of thinking is misguided.
I may have misquoted. The point I was trying to make was that you often have to make tradeoffs between--what is it now-- scope, resources (time, money, manpower), and quality. If you want to meet a deadline, you may have to either reduce the scope or suffer a decrease in quality. If you increase the scope and want to maintain quality, you need more time and money (and perhaps people). And so on.
 
Mark Herschberg
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Junilu Lacar:
All I can say to that is "Cheap, fast, good. Pick two."


Originally posted by Ilja Preuss:
I like to think about not doing a necessary refactoring as taking on a "design debt". You are paying interest for this debt from the very first minute on until you decide to settle them.


I agree with both sides--in different contexts. Junilu is correct in that generally when you model a process, you can't optimize everything. But this is a relative constraint. The process can't be made more efficent and arguably refactoring does that in the long run.
--Mark
 
Mark Herschberg
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:

Mhh, better than planning for a cleanup phase might be to plan for becoming one of those top companies. What do these companies do to not get "a little sloppy" in the final push?


With all due respect, I think this is a bit naive. It's easy to say, "just do it the right way." but realistically, you can't change the process overnight. Many companies won't change; event those that will, will change slowly. In many cases you have to take a realistic approach.
As an example in my last company, I managed a group of kids right out of school. No process, no documentation, no tesing, etc. They were used to working as 8 people in a room and shouting out whenever communication was needed. I presented concepts like process and testing and documentation and planning. You think they did it all well? I settled for having a couple documents done ahead of time, and most of the code being javadoced. I settled for code being tested before it got checked into the code repository. I settled for some testing being done before it was released. That's a long way from ideal.
Yes, you should work towards becoming one of those top companies. But in the mean time, I think this is a practical half-way step.
--Mark
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There's another point I feel needs stating here.
For me, the key point of refactoring is not to make the code smaller, or faster, or prettier, or any of the other things which might justifiably be left for later.
The key point of refactoring is to make the next change to the software (the next feature, the next bug fix, the next unit test) easier and quicker. I might spend 20 minutes now, to refactor the code I have written in the last hour, so that the next bit of work can be done in half an hour rather than an hour.
Kent Beck claims that the root of all refactoring is removal of duplication. And every duplicated bit of code which is removed (be it ever so small) is one less bit of code which needs to be edited when something changes.
Refactoring (just like unit testing) helps me go faster right now, in the short term.
Sure, if your project deadline is less than half an hour away, then maybe you can skip refactoring, but if it's any further than that, refactoring can help you get more work done in the remaining time.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Originally posted by Frank Carver:
Refactoring (just like unit testing) helps me go faster right now, in the short term.
Sure, if your project deadline is less than half an hour away, then maybe you can skip refactoring, but if it's any further than that, refactoring can help you get more work done in the remaining time.

I agree. However, there is a learning curve involved and in the early part of it, you're not really sure of what you're doing so you tend to either not refactor enough or refactor too much. Couple that with test-first programming and you get a double whammy. Consequently, progress may be perceived (especially by uninformed management) as being slower than when you weren't refactoring. Until you get into a comfortable rhythm and become familiar with the mechanics of refactoring, it's easy to see this as a liability rather than a necessary investment in the learning process that will give substantial returns with practice.
 
Mark Herschberg
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Junilu Lacar:
I agree. However, there is a learning curve involved and in the early part of it, you're not really sure of what you're doing so you tend to either not refactor enough or refactor too much. Couple that with test-first programming and you get a double whammy. Consequently, progress may be perceived (especially by uninformed management) as being slower than when you weren't refactoring.


Well said Junilu. This, btw, is true for using any new tool, technique, or process. The learning curve may be a few days, but is often a few weeks, and sometimes a few months. Naive management sometimes cancels initiaitves for this reason.
While the concept of refactoring is fairly simple. The actual activity isn't too hard, either. But the instinct to do it well definately takes time to develop.
--Mark
 
Rishi Singh
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Frank
"The key point of refactoring is to make the next change to the software (the next feature, the next bug fix, the next unit test) easier and quicker. I might spend 20 minutes now, to refactor the code I have written in the last hour, so that the next bit of work can be done in half an hour rather than an hour"
So u mean to say that there should not be seperate time-frame for refactoring, it is just after u have finished coding your stuff, u take some extra time to see that in future if u need to extend it, it takes less time and effort.
"Kent Beck claims that the root of all refactoring is removal of duplication. And every duplicated bit of code which is removed (be it ever so small) is one less bit of code which needs to be edited when something changes."
what if the removal of duplication is not possible.Sometimes it becomes inevitable.Here i would like to ask how do u foresee the difference between code optimization and refactoring.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rishi Singh:
what if the removal of duplication is not possible.Sometimes it becomes inevitable.


Then, obviously, you are stuck with it. Can you give an example of duplication that can't be removed?


Here i would like to ask how do u foresee the difference between code optimization and refactoring.


I don't understand this question...
 
Rishi Singh
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ilja,
how would you defferentiate between code optimization and code reafctoring.?
Sometimes when it is inevitable to remove duplication and you do get stuck up , how do u then refactor it ..by starting all over again.?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Frank Carver:
I might spend 20 minutes now, to refactor the code I have written in the last hour, so that the next bit of work can be done in half an hour rather than an hour.


Even better, you might spend 2 minutes now, to refactor the code you have written in the last 5 minutes.
Refactoring should simply be part of your every day coding. If management can see you switching between coding and refactoring, you are not doing it often enough...
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rishi Singh:
Ilja,
how would you defferentiate between code optimization and code reafctoring.?


I think they are totally orthogonal concepts.
Refactoring, done well, is working in *very* tiny steps, with rather local impact - you rename a variable, extract a method etc. It is also most often triggered by a very local problem in the code, a code smell.
Optimization is (or should be) triggered by a more global problem in general - some part of the system isn't working fast enough. So you start to profile the system to find the bottleneck (so I hope). Removing this bottleneck often, though also local, isn't *as* local as a refactoring - you need to take the bigger picture into account.
So you *may* end up making the same changes to the code, but the focus/feeling seems to be rather different to me.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rishi Singh:
Sometimes when it is inevitable to remove duplication and you do get stuck up , how do u then refactor it ..by starting all over again.?


I don't know - till now it didn't happen to me. I wonder how starting over would help. Do you have an example?
What happened to me is that I had duplication that I found to be to costly to remove in Java, so I just didn't remove it.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mark Herschberg:
With all due respect, I think this is a bit naive.


I don't think it's naive, but very optimistic - by intention.

It's easy to say, "just do it the right way." but realistically, you can't change the process overnight.


Yes, it's easy to say. It's possibly not so easy to start to do it. But if you *focus* on interim solutions instead, the process won't even change over the months, IME.

Many companies won't change; event those that will, will change slowly. In many cases you have to take a realistic approach.


Are the top companies the ones who took a "realistic" approach, or the ones who did the right things albeit they "couldn't"?

Yes, you should work towards becoming one of those top companies. But in the mean time, I think this is a practical half-way step.


Well, I guess we are in fact on the same page here. It's just that I too often encountered that "that would be best, but we can't do that right now" translated to "we will never be able to do that".
 
Mark Herschberg
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
Well, I guess we are in fact on the same page here. It's just that I too often encountered that "that would be best, but we can't do that right now" translated to "we will never be able to do that".


I concur that this is dangerous. I think the key inflextion point is the difference between your statements. Someone who says "we can't do that right now, so let's forget it" won't make it. Someone who says "we can't do that right now, but maybe we can do this instead," will. The point is whether improvement is undertaken, however slowly (within reason), versus being stagnant.
--Mark
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic