5 Principles to improve your Code Quality
Since I write software I am conviced that this is not just a kind of a technical handicraft but also an act of high creativity - say art! Since I work with different people to produce software code in a team I wonder how different working styles, the different personal and professional backgrounds, and the chaos of … uhmmm … artistic individualism can lead to high quality. To often there is chaos in the code as well, even if individual modules seem to be almost perfect. I want to name 5 fundamental priciples every programmer should follow to prepare the ground of high quality software because upon this ground there is enough space to use his / her own coding and working style as a valuable part of the whole.
1. Simplicity and Elegance!
Simplicity is not always elegance and elegance is not always simple. But in coding there are some strong links between both. In my eyes simplicity means that the complexity of a system must be adequate and comprehensible. Every part of a system should add something distinct and valuable to the whole. The parts are associated together by similarity or domain and don’t hide any nasty surprises. Achieving this is not easy. Simplicity is not easy - it’s hard work of understanding what the code is for and how several parts can be abstracted and substituted. The coder have to recognize patterns within the code and between several projects to identify modules that can be added to common libraries… and so on. A good use of interfaces underlines the simplicity - the coder reduces the complexity of system parts for other parts or other developers that use a system.
And there is a state of simplicity that is somehow elegant or aesthetic. It takes time to really understand that.
2. Give it a proper Name!
When you really know the “thing, be it a class, an objet reference, a variable or a function, there shouldn’t be any hassles in finding a proper name. Names can help you to think about the concepts and functionalties you write or use while developing and they should help you to understand the code while reading it.
3. “Make it readable” equals “make it understandable”!
Your audience is not just the compiler and yourself. It’s other programmers, your team mates, possibly your client or your successor (when you decide to leave). And it’s part of your job to write code for their benefits. There are three simple words that summarize what to do: The three C’s - Consistent, Conventional, Concise!
- Consistent
Develop your own style and use it throughout your code parts and projects. If you are coding for a company adopt the “house style” and use that instead of your own. It’s somehow stupid that there are so many fights about how to set brackets, how to intend code, how to insert comments or even how to sort the member of classes. I say: Fight if you want to but stick to the result whenever you find one. - Conventional
Even if you have your own style let it be based on one of the industry standards (e.g. K&K Brace style, Extended Brace Style, Intended Brace Style …) - Concise
Know what you are doing and why. If someone asks you why you write it that way, know your arguments - Think about it! It’s important whenever there is a new team member who has to adopt your style and that is not easy if there are no good reasons to use it.
4. Be defensive!
Be careful while coding! Don’t code in a hurry! Think about what you are doing: It’s engineering and solely because it’s just writing some code to a computer it is still some kind of construction. And construction has to be safe; otherwise there is a high risk of a (system) collapse. Therefore a good software developer has always to be doubtfully about the correctness of some piece of code. He never should assume the context in which a function is called, he should not assume that a function never will nver produce an error and that nobody will try to access that function in ways it is not meant to be called. Some additional points to have in mind when coding the defensice way:
- use safe data structures
- check every return value (even if it’s just a standard function you used already for thousends of times)
- handle memory carefully
- initiate variables always when they are declared (or use the constructor of a class to initiate fields)
- check numeric limits
- add preconditions, postconditions and check vor invariants within functions
5. Selfdocumenting Code needs less documentation!
Edwin Schlossberg: “The skill of writing is to create a context in which other people can think” (found here) When you code always think about others that have to read and understand what you did later on. You only need to comment that fundamental parts (classes, funtions) and avoid extensive inner code comments when you choose meaningful names, avoid redundance, have clear data flows, strict separation of concern and very high cohesion.
Just think about a function call “int x = r12.s(3);” where you also could write “int innerSize = room12.getSize(Room.INNER_SIZE);” Got it?
