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 things 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.
It has been pointed out by many that mixing concerns is 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 increase 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.
This idea of separation of technical and business, or generally, domain logic concerns is emphasized by the current popularity of domain-specific languages (DSLs). Within this approach the domain logic is expressed in a dedicated language specialized for the given domain which can ideally be edited by domain experts who are not programmers. DSL authors strive to make statements in the DSL sound just like "plain English." While this probably can help to improve communication with domain experts, careful design of short methods with low complexity which focus on a single fine-granular concern and proper expressive naming of methods and variables will certainly 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