Refactoring – An analysis of intent (Part II – Understanding)

Summary: We can roughly taxonomize the type of understanding needed from source code by considering:

• Whether the reader is trying to understand what code does or how it does it.
• Whether the reader wants a vague or exact understanding.
• What fraction of the code is the reader trying to understand. Are they just trying to understand a local area or are the trying to understand the program globally as a whole?

For each type of understanding, some types of refactoring may make understanding easier, whilst others may make it harder. This is particularly relevant for vague understanding and local understanding.

Regardless of what the reader is trying to understand, some things just make reading code easier. Writing code that is the same as – or analogous to – code that others have already written makes understanding a lot easier. Making code consistent allows the reader to remember a limited set of rules rather than actual details. Doing what people expect means they won’t be suprised and confused. With this is mind, we see that using patterns and idioms makes code a lot easier to read – provided that the reader knows the idioms and patterns. Some refactoring may be good at doing this – other refactoring might be bad…

---

Refactoring – An analysis of intent (Part I)

A mild warning. This article is more about idle philosophizing about refactoring in general than giving practical advice. I wouldn’t claim to be massively experienced with this topic. However, reading other people’s philosophizing might still be useful – if only to find things that you disagree vehemently with.

---

How should one refactor code? When should one refactor code?To answer this question, it is probably useful to consider the motivations behind refactoring in some depth.

Since refactoring as defined elsewhere specifically excludes the functioning of a program, the purpose of refactoring is to increase the reusability of code. (Where maintainability is included within reusability).

This means that refactoring is meant to make code easier to use in the future. Let’s think about how existing code is used.

It can be:

• Understood (e.g when trying to fix bugs, extend, interface to)
• Changed (e.g we might want to fix bugs, change default behaviour, add new behaviour or fork the code and use it for a completely new purpose)
• Interfaced to (i.e used) (e.g we can call methods in the code, or use its classes)
• Copied (e.g sections of the code might be removed and used elsewhere, or the rough outline might be used as the basis for someone elses program)
• Used in a way that I haven’t thought of yet.

When I find time and enthuism I’ll try to write about each of these uses in turn.

Switches should include all cases

It would probably be useful if all switch statements contained labels corresponding to every possible value of the switched variable rather than using the default case to pick up all the missing cases.

This means you end up writing code like this:

switch(var)

{

case ONE:

     ...case UNHANDLED1:

case UNHANDLED2:

case UNHANDLED2:

default:

    ... ((deal with default case))

}

The advantage to this approach is that a reader can tell when a case has been unintentionally left out or not yet implemented at a glance. Also, as a side effect, when programming in this manner one is less likely to forget about cases – since one is listing all case.

This is an example of a more general idea of programming so as to make one’s intent clear… you just have to bear in mind that making one’s intent clear is secondary to making something that works.