A large part of today's software is written using object-oriented languages. Object-oriented software is composed of objects communicating via methods. So in a way it can be argued that not objects but methods are the basic building blocks of our code. While there is a lot of literature on design in the large — architecture and components — and on medium granularity — e.g., design patterns — surprisingly little can be found on designing individual methods. Design in the small, however, matters. A lot.
Ideally, any piece of source code should be readable like a good book: it should be interesting; it should convey its intention clearly; and last, but not least, it should be fun to read.
The simplest way to achieve readability is to use expressive names that properly describe the concepts they identify. In most cases this will mean relatively long names for methods and variables. Some argue that short names are easier and thus faster to type. Modern IDEs and editors are capable of simplifying the typing, renaming, and searching of names to make this objection less relevant. Instead of thinking about the typing overhead today, think about the time saved tomorrow when you and others have to reread the code. Be particularly careful when designing your method names because they are the verbs in the story you are trying to tell.
Another source of readability and comprehensibility is brevity. As a rough guideline for an appropriate methods size I would argue for usually no more than 7±2 lines of code. This is motivated by applying the famous Rule of Seven which roughly states that the average human being can keep around 7 items in short term memory. In any case, make sure each method can fit on your (and your co-worker's) screen.
Keeping it simple (KISS) is a general rule of thumb in software design. One way of applying this to methods is to keep the cyclomatic complexity low — ideally under 3 or 4, definitely under 10. Cyclomatic complexity is a numeric value that can easily be computed by many tools and is roughly equivalent to the number of execution paths through a method. A high value of CC complicates unit testing and has been empirically shown to correlate with bugs.
Mixing concerns is often considered harmful. This is normally applied to classes as a whole, but also applied at the method level it can go a long way to increasing the readability of your code. Applied to methods this means that you should strive to map different aspects of your required behavior cleanly to different methods. Such a separation of technical and business concerns facilitates, and benefits from, the use of a well-defined domain vocabulary. Using such a vocabulary helps to reveal intention in your methods. This can ensure that a consistent and ubiquitous vocabulary is used when speaking to domain experts, but it also ensures that methods are focused and consistent, so that developers benefit.
All in all, careful design of short methods with low complexity that focus on a single fine-grained concern and proper expressive naming of methods and variables will definitely help to better convey the intention of your code to other developers — and to yourself. This will improve maintainability in the long run and, after all, most software development is maintenance.
Happy method design!
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Programmer Should Know home page