From the translator: today we are publishing for you an article by a developer from India, Ravi Shankar Rahan. He
talks about what to do if you want to learn how to write simple and clear code. The article is recommended to all novice programmers.
Write a simple code is easy. But if it’s about being ready for future use by anyone, then everything becomes complicated at once. The fact is that such code should be even more clear and understandable.
')
The developer needs to create code that can be used by any of his colleagues from any country in the world. So he becomes something like his "heritage". All this sounds nice and smooth, but the reality is somewhat different ...
Skillbox recommends: A two-year hands-on course “I am a PRO web developer . ”
We remind: for all readers of "Habr" - a discount of 10,000 rubles when recording for any Skillbox course on the promotional code "Habr".
The fact is that at the beginning of my path, even accepting the dogma set out above, I created such a monstrous code that it could not be called "good". It was almost impossible to understand and interpret. A little later, I began to spend days and months over the "correction" and "revitalization" of the monsters I had created.
It is difficult to program. When you write a program in which dofigalions of strings, you make mistakes. Sometimes they are significant, sometimes - not very. But regardless of size, time is needed to find and fix them. Sometimes you need help getting out of the funnel of despair and hopelessness that you find yourself working on your code.
Sometimes you need ... a rubber duckThe concept of a rubber duck was first proposed by Dean Parker
in his post on oratory. Parker says that in order to become a good speaker, you need to constantly practice speaking. And the best way to get rid of the fear of the listeners, while learning to express your thoughts in a smooth and intelligible way, is to speak during a “oratorical training” before a rubber duck. It just replaces the listeners.
As a programmer, you need to try to explain each line of your code to a rubber duck (whether real or imagined). Trying to do this, you begin to understand the advantages and disadvantages of the code. You give yourself the opportunity to look at it from the side.
Here are some important points that I understood by applying this practice. They helped me start writing noticeably better.
Creating reusable components is not a permanent needMany will disagree with me, arguing that reusable components are always needed, that they need to be reused as often as possible. Say, it helps to improve the quality of the code and work on their own mistakes. All right, but only if you create the best code in the world. And he just is not needed by anyone.
Of course not. You need to create software that meets certain conditions, including the budget. You can also constantly polish your project, bring it to shine, losing time, but feeling like an ideal developer. But remember: software is relevant for a limited time, which means you need to work quickly, otherwise you will never finish.
You aren't gonna need itThe original English axiom sounds like “YouArentGonnaNeedIt (YAGNI)”. It should be understood as follows: “Use certain tools only when you really need them, and not just think that they can be useful to you.”
There are two reasons for this:
- You save time by avoiding unnecessary work.
- Your code gets better, because you eliminate it from the "supposed" elements that would complicate the program.
Simplify everything to the minimum necessaryExtreme programming has two golden rules for creating simple code.
First of all , the easiest way to introduce a new function is to make it “just work”. No need to create chic superstructures, something highly technical. Just make it work. But do not forget that the code must pass Unit Tests.
Secondly , refactor the system so that the code becomes as simple as possible, with the inclusion of all current functions. It should be as clean as possible.
Third , it is worth learning that we are not looking for the fastest way. We strive to achieve the simplest result (in terms of code). For example, you can break an existing method into parts, which will leave test fragments working, and then modify each processing method, step by step.
When you get stuck next time, try the duckSearching for bugs, problems, general work on the code is the main part of programming. Therefore, developing your own techniques for finding and eliminating bugs, finding your way is a critical task.
If you're stuck somewhere and nothing works, try a duck.
You can not imagine it and buy. It doesn’t matter whether it is a common duck for a bath or a duck pirate - the main thing is that you feel comfortable with it, so that it matches your individuality.
And after that you can start a conversation with a duck. Talk to her, ask questions, explain out loud the problem you are working with. The result will surprise you.
Chris Pine was right to say, "Programming is not something you know, it is something you can learn."