In my last post I talked about how important it is to have good communication between developers in a team. In this post, I’ll talk about how you can use code as a tool for communication.
Communicating well is hard even when the team is sitting nearby, and can just stand up and walk over to each other. But when the team is dispersed over several continents it’s nearly impossible. Or even worse, what about when the team is spread out over a couple of years? The team might even be you today, working with yourself two years in the future.
Code has three separate values:
1. Functionality
This is what the compiled code does – what the end user will see. Here I also count more intangible things like performance and security.
2. Flexibility
How easy/hard it is to add new features to the code base. It might be brand new functionality, or changes of old functionality, like supporting a new database system.
3. Readability
How well the code communicates to the code reader what it does.
Unfortunately, developers favor #1, sometimes think about #2, and rarely think about #3. We tend to focus on getting the program to do what we want it to do, and forget about the perils of complicated, confusing and hard to read code.
So what can you do to improve the communication value of code?
There are tons of things you can do. Among the most important is to keep your classes and methods small. I mean really small – a method longer than 20 lines is hard to understand.
As a rule I try to keep all my public methods no longer than 10-20 lines. I want anyone using my classes to be able to look at the source and immediately understand what the method does. Not all the small details, but the big picture.
More tips on how to keep the code clean and readable to come.
* long rambling deleted*
Sufficient to say; give methods good names, don’t ‘hide’ semantics behind bad function names, and avoid creating methods with different semantics depending on data hidden within parameters (most notably parsed string values). Create two methods instead, with clear responsibilities.
Left by Stefan Andersson on March 23rd, 2006