Clear is better than clever, according to Dave Cheney
If you are a coder or you are just beginning on this new programmer life you have to know already that read code is essential. No matter the level you are being able to read is not entirely up to the reader or end user programmer.
Haven’t you been on that position where you are just starting reading a new library or language and the documentation is really bad. This can be caused most of the times of lack of examples or bad writing description. Clear code is the better way to keep your code ready for any possible event. Not just for your team or other people but for you in a near future you’ll be able to modified and even reused for any possible outcome.
Clear code is the first optimization aspect. Readability can be subjective sometimes because of your learning process, and everyone learn different and there are multiple ways to do a simple operation or statement. When a code base is unreadable it means you don’t get it yet. Clarity for the other hand is the property on the code of the page. Not how it works or how is build but what the code define. The goal is not how fast you can read a piece of code but how quickly you can get the meaning of it.
When I previously said that the code can be written from a lot of different ways this does not mean that you can end up with the first one you code. Maybe at first but once you are done you could grasp some meaning to it for a better clarity. For example, when you write a conditional statement function you will need to detect some (not all because it is not possible yet) possible outcomes:
But having
separate condition may seem that the code do different things on this comparison method. We have to follow a simple sequence. We could add an else if or even and else because you can never be so sure:
In this structured programming sequence you return a different value for every different condition. And by applying this structure clauses you make emphasis on its behavior. It is more what the code is trying to do and not how its trying to do it.
Readability versus clarity. One of the principles of structured programming. Code is read more times than its written. Hundreds of users at certain point of time will read a piece of code. And the result will be that the machines execute that code, but that is secondary. The issue sometimes is that when you code something that only you will code once becomes easy to decide how to write it easily. That is valid but when you enter into a maintainable project not may seem to a good idea on the long run. The first steps into making your code maintainable is making sure that the code is clear.
Simplicity leads you to maintainable code. Sometimes you may not interfere with some code because you are afraid to stop working if you mess whit it, not because is unstable but because is complex or understandable this situation are the worst practices because not just you are being the victim of a bad written code, but you will let other people on the future to stress up and continue with this error practice.
Productivity is another go principle. According to Cheney, go is a language where you have to feel that you can get a lot done. Almost the same as the same feeling that every coder have with python. The difference is that python may be unreadable if the programmer decides to. But with go is merely a principle not to make it clear but takes this as an inspiration for being productive and having where to rely on.
The conclusion is that the code you write today may define the behavior of not just your program but the company you are there for.
