I’ve sometimes been asked why I insist so much that code should be as readable as possible—easy to read and understand, without strange constructs or classes hundreds of lines long scraping at your eyes, to name just a couple of examples.
There are many arguments for putting a little extra effort into writing code that others can understand. Of all the possibilities, I think one fundamental point is not always given enough consideration.
Any piece of code will be read many more times than it will be written or modified. That is, any method, function, class, and so on will be reviewed and read more often than it will be revisited for a small modification. So if every one of those occasions carries a time cost because of the complexity of understanding what we read, we face an obstacle that takes time away from more productive or creative work.
We don’t write software for ourselves, but for others to understand. This is key to creating maintainable, evolvable solutions. Sometimes we forget that we ourselves may be that other person.
Did I mention extra effort? In reality, we have to make that effort consciously if we aren’t used to following the good programming habits that apply to this particular subject. These include simple, obvious things such as choosing good, descriptive names for our software artifacts (why call a variable _nde when we could call it _numberOfEntities, for example), writing methods or functions that do just one thing and take no more than three or four arguments, keeping class members in the same order throughout the solution, and a very long list of other practices.
I believe that anyone who doesn’t try to write readable code isn’t really interested in doing a good job; they are leaving stones in the path for a colleague to trip over when they have to take over that code.
What’s surprising is that writing something in a complicated way often takes exactly as much effort as writing it simply! If we have both options, why not choose the one that makes for better work?