I code with a “less is more” mindset. Typically, adding more lines of code doesn’t make something better, it’s just more noise. I prefer to keep things clear and concise. I also have a “keep it simple” mentality, preferring to write straightforward code, and avoid clever abstractions.
Old programming wisdom tells us that to debug code, you need to be smarter than the person who wrote it. If I use all my smarts to write code then I am, by definition, not smart enough to debug it.
During the past months, I’ve been changing how I write code a bit. I’ve identified that I focus too much on keeping the total amount of lines low. Keeping code concise is great, but obsessing too much with total lines of code is impairing my ability to write better software.
I’ve recently been writing more code, but shorter functions; a larger amount of simple abstractions. A function with 90 lines is pretty hard for a human to follow. Splitting it into multiple functions with clearly defined scopes is typically easier to understand and maintain. These multiple functions might be 30% more code in total, but I only ever need to keep in mind a single one of them. Ideally, what each function does is explained in a short brief sentence. When reading the code for any one of these functions, I only need to remember what the others do, but don’t need to worry about their internal implementation details (i.e. I don’t need to remember how they do it).
Too much code is not good, but too little code is also not good. Try to find the sweet spot. Don’t be scared of adding more code, especially if it removes code from the already-complicated places.
Most of what I’m saying today is obvious, and some of it are lessons that we learn during the first couple of years of programming. Yet it’s still wisdom that we should all remember to reflect upon, even after a few decades of coding.