This line, this method, this class, this file, this directory—how long should they be?
Lines
At the start of my career, the in-vogue line length for formatting purposes was 80 characters max in the teams and projects I was involved in. It could wrap at a natural place, but screens got bigger and wider, and printing on a dot matrix printer was no longer required for code! Over the years, this recommended line length drifted to 100, then 120. Somewhere around here is probably sensible and could also vary depending on the language.
In the line length debate, I always found it interesting to think about why a line would need to be wrapped, especially when it looks nicely formatted but spans over four lines. Maybe, in that case, it’s the overall design and implementation that is the issue. So, my first thought is: How could this be improved? Some causes can include overly complicated conditional statements, which I have written in haste and later regretted. Or over-coupling, where the value of interest is a member of a class who is a distant relative to the current class, i.e., getX().getY().getZ().getSomethingElse().
As is often the case, with some better design with low coupling and separation of concerns, those line lengths might just shrink themselves. The choice of names, as always, plays its part. Or it could be that whatever is taking up 4 lines in your conditional statement could be abstracted into a method that returns the same result and might in addition provide some clarity to why the condition is important.
Methods
Wouldn’t those nice, neat lines be so much easier to understand in some lovely, simple methods and not some 100-odd line monster bloated with multiple depths of nested conditional statements? It’s often not easy to put a number on these rules, but if it doesn’t fit nicely on the screen with room to spare, then it’s probably too long. Have your methods do one thing. Quite often, things are referred to as the “S” in the SOLID principle, but I think this is just common sense. Keep it simple, and compose and combine your simple things into glorious, beautiful code.
Classes
Well, you get the idea. Keep your lines as short and concise as possible through good, sensible design, refactoring, and refining, leading to simple, glorious single-responsibility methods and combine it with some sensibly sized classes. I talk about classes because I am a long-time Java guy, but wherever you gather your methods together in a file, my preference is for conciseness. Just big enough for the collection of methods or functions that logically belong together. If it’s thousands of lines long, then again, the red flag is there. Abstraction, inheritance, and composition are all techniques available to refactor classes of this size into smaller, manageable pieces.
Directories
There are usually logical ways you can break down your classes into packages and files into directories that again don’t let them run out of control. I find this helps see the wood within all those trees—a directory tree, of course.
Summary
As you can guess from this article, my own style is concise. Smaller and shorter is usually better and very often much easier to test and maintain. In addition to be concise it should follow that it is easily understood. I baulk at long endless lines of code going over many lines, in massive, long complex methods within gigantic files or classes. I know that we have great tools that make it easy to navigate, search, and see the structure of source code, but equally, it is a mindset to be neat and tidy when developing code, keeping the house in order and striving to imagine the next person to maintain that code might feel compelled to write a strongly worded email on the mess they have inherited.
