QualityCode.com Essay: What Does Extreme Code Look Like?

Extreme programming (XP) is a process to develop software. So I can’t really point to a program that is, itself, “extreme”. However, there are some characteristics that most programs developed using XP would share. Here are a few I can think of:

  1. Automated tests. XP projects typically generate roughly equal amounts of production code and unit test code. The unit tests exercise virtually every line of code in the system, and report back with a simple pass/fail so it is easy to know if anything is broken.
  2. Very modular code (with high cohesion and low coupling, if you are familiar with those terms). This is partly due to the tests, because code that is not modular tends to be difficult or impossible to write automated unit tests for. It is also due to the frequent refactoring that XP teams do. If you see a way to improve the design of the code, you do it. The tests protect you from accidentally breaking something.
  3. Very simple designs. In XP, you don’t build any infrastructure, or add any hooks that you don’t need right now. This leads to code that is far simpler than you would tend to get with other approaches.
  4. Very clear code, with precise naming. Since the code is continually being improved, the names can evolve over time to remain clear and accurate. When using XP, you rarely retain documentation artifacts outside the code and tests, so the code and tests must clearly communicate your intentions. Duplicated code, in particular, is frowned upon and removed whenever possible.

Most comments are considered to be baggage that cost time to keep in sync with the code, and which may at any time be inaccurate1. Therefore, comments are viewed as a signal that the code in that spot should probably be cleaned up.

In a true XP project, all code would be written by pairs of people (two people, one computer, one keyboard), and all the code in the system would be communally owned, so everyone is familiar with all of it. Those factors also tend to help code clarity.

1 Documentation of public APIs, of course, is still helpful and necessary. This statement refers to comments which try to explain what the code is attempting to achieve, or how it is doing so. I realize this remains a controversial stance.