# Wednesday, November 10, 2004

I'm currently reading Martin Fowler's Refactoring: Refactoring: Improving the Design of Existing Code which is an interesting read given that I have started doing some of the things he describes in the book on my own. It's an interesting way of being validated and gaining an even better grasp of what is possible with the technique.

One thing I find troubling though is his section on the problems with refactoring. He himself mentions that the section is shorter than he'd like it to be and that the reason for it being that way is that the field is young and we need to gain a better understanding of it.

Great I'm with him so far but I got thinking about a potential problem with refactoring and the notion of "beautiful code". I may be missing a crucial point and I admit that I haven't read through the entire thing yet but from my point of view a critical problem with the before mentioned notion of beautiful code is that different people have different ideas of what is considered clean and beautiful code.

Now I don't know about you but I've not yet worked on a project where I was the only developer in action. One of the things Martin Fowler promotes is that you should refactor whenever you encounter something which you need to gain a better understanding of or if you are actually trying to improve in the existing design. He gives an example of using refactoring in code reviews in order to better understand what the code does.

What I see as a problem is that when different people are looking at the same code with different ideas of what beautiful code is we may end up in a situation where one person refactor another persons code, the person who wrote the code in the first place may not agree with the changes and refactor yet again, and so the story would continue without really adding any value to the overall product.

The situation which prompted this though is code review on some of my code a while back where the reviewer noted that I was using the C# one-line conditional assignment in a lot a properties, I don't actually know what it is called but an example would be

string s = ( 1 == 1 ) ? "OneEqualsOne" : "OneDoesNotEqualOne";

Now what the reviewer noted was that I should use the full blown if-construct because this would be easier to read. Here is the kicker I disagree but had he used refactoring in his code review he would have simply changed my code to use the if construct. Later I might have revisited the code and noticed those changes and went ahead and changed it back.

Of course the above example is very simple and we wouldn't keep changing that small detail back and forth but it seems to me that refactoring is very much dependent on a development team having the some idea of what constitutes clean code.

Comments are closed.