Refactoring Friendly

Some features, idioms and styles affect the scope of a refactoring session. First some examples (mainly from Java):

For these and many other reasons, refactoring in Java is harder than refactoring in Smalltalk. There is an argument that Java programmers should consciously adapt their style to make refactoring easier. For example:

Alternatively, we could be content to break the refactoring into smaller units. Where cascading changes are necessary, find the minimum at each step necessary to satisfy the compiler. On MethodsShouldBePublic, RonJeffries puts it like this: The idea is that the system be allowed to remain in a "bad" state, temporarily, so we can postpone some of the work of the current refactoring session to a later one (perhaps only a few minutes later). This is often hard in Java, but perhaps good advice for language designers.

One practical idiom would be: Contributors: DaveHarris, RonJeffries
This is partly motivated by the pages cited, but also a recent discussion in comp.object in which BertrandMeyer argued that good languages should never offer compiler warnings. I'm still interested in the differences between his attitude (shared by much of Java), and the Smalltalk/XP community. -- DaveHarris

"Don't use exceptions."

You can get around the problem cited here if you DeclareThrowsExceptionByDefault. You can use the other CheckedExceptionPatterns to deal with the other problems raised by exceptions in Java. -- PhilGoodwin

Better tools could make many of the necessary transformations easier.
Wiki pages are easier to refactor if you write in the third person.

If you take a subjective ThreadMode comment written in first person and convert it to a document mode OpeningStatement you pretty much have to rewrite it. Is this a bad thing?

Well, it's more work anyway. I think that it's better to leave the thread mode as is and use it as inspiration to write a new DocumentMode OpeningStatement. -- PhilGoodwin

View edit of February 2, 2010 or FindPage with title or text search