There is a lot to say for making code maintainable. Maintainable code is more reliable, easier to modify and update, easier to test and verify, and easier to create. What defines maintainable code?
ISO 2510 defines maintainability as
- Modularity
- Reusability
- Analyzability
- Modifiability
- Testability
You can use SonarQube to test your code for bugs and code smells. I recommend using SonarQube, it points out many quality issues to you. You can read the books, like there is Code Complete, or Design Patterns, or Antipatterns. You can have coworkers review your code, you can do pair programming. It all helps to create better code.
However, there is one thing that trumps all of these: readability. Or better still: beauty. I will explain.
I have seen a lot of code, in the past decades. Code in Fortran, Cobol, C, Assembly, Tal, Prolog, C++, Java, Javascript, Python, Kotlin, PHP, Perl, and more. I like to see code that looks nice. The source code should look nice. It should be well formatted, consistently spaced and formatted, it should have white space between the bits that belong together. Consistently formatted is more important than how it is formatted. I like a curly bracket in Java to be at the end of the line, but if you want them at the start of the next line, OK with me, as long as you do it that way in the whole code base. Beauty is not primarily the formatting, though. Beauty is in the way it works. Beauty means the code is not too verbose. It also means it’s not to concise. More often than not, four lines of code are easier to read than the same code crammed into one line. Code that you can read quicker is better. It’s more beautiful.
Beauty is subjective. You can find a painting by Edgar Degas beautiful, or you may not like it. We do agree that Degas was a skillful painter. We do agree there is a beauty in his paintings, even if it’s not your definition of beauty. If you like a painting, it is hard to explain why you like it. Take “Champ de blé au corbeaux” by Van Gogh. You can like it because of the colors, the yellow fields against the blue sky with the black crows. Or you can like the composition. Or you can like the touch, the way the paint has been put on the canvas. Or you can just like it, without being able to explain.
I feel the same about code. If it looks good, the code is not too verbose, nor to concise, the field names are chosen properly, the methods are only a few lines, the classes don’t exceed 100 lines, there are no lines you don’t understand at first glimpse, than it is beautiful. This means, the programmer has thought about and paid attention to the structure of the code, the verbosity, the complexity, the readability, the layout, everything. When a programmer writes code, aiming at writing it so that they feel good about it, I’m sure that the code is easy to read for others. If the creator feels good about it, probably the maintainer who comes in two years later to make updates, feels good about it too, in much the same way as when Degas feeling good about a painting and another painter seeing it later, feels the same. My granddad has worked with Bart van der Leck for a brief period of time, and while he did not admire Van der Leck’s paintings, he did admire the man himself. He saw a beauty in Van der Leck’s work, even if it was not the same kind of beauty he saw in Van Gogh’s paintings. Grandpa explained in detail to me the many shades of gray Van der Leck created, saying “there is a special shade of gray for every person”.
Your coding style may not be the same as mine. But I’m sure that if you feel good about the code you write, I can see that, I can see the beauty in your code. So, maybe I should define “beauty” in programming as “the creator of the code feels good about the result”. Assuming, of course, the programmer is skillful enough for judging the code and is well past the valley of despair in the Dunning Kruger curve.
If you feel good about the code you wrote, then I’d call it beautiful code, and it’s maintainable code.
