
This is a translation of Michael McKee's
post . Michael is a professional programmer who from time to time shares his experience and skills with colleagues, both novice coders and professionals.
Most programmers are the last thing to think about the aesthetics of the code they create. Of course, almost everyone adheres to the general rules. But what if you go on? A good code, first of all, should work. But I think that he should have his own style, this concerns not only the content, but also the form.
Skillbox recommends: Practical annual course "PHP developer from scratch to PRO" .
We remind: for all readers of "Habr" - a discount of 10,000 rubles when recording for any Skillbox course on the promotional code "Habr".
In fact, it is not. Here are some problems faced by all novice programmers who are engaged in self-education. There are tons of articles and notes about this, but I want to tell you how to arrange the code visually so that it is not only correct, but also looks good from the outside. I believe that you can express yourself not only in the visual arts - it can be done always and everywhere.
')
Organization of work is very important for me, as well as its visual form. Ruby is a great version of a programming language, as if specially made to meet my requirements, because it allows us to do what we want without any problems. He is flexible, stylish and logical.
Let's look at this example.

Even a novice programmer will understand what is wrong here. This code is just painful to watch. But the corrected version, which already looks better.

Phew! Much better. Now we see what relates to what and how. But this code can be improved. Declaring attr_reader and attr_accessor can be made even more expressive.

Announcement of each new attribute from a new line is much easier to read. Now we have a list of attributes that are assigned to each accessor. You can go further.

Here it is already easy to understand where there is only the possibility of reading, where there is read and write.
Let's now look at the next part of this class, the initialization method. Here you can do a lot of things.

In principle, the code is read, everything seems to be fine. But you can do better.

If you put down all the assignment operators in one column, it turns out very well. Looking at this code, it is easy to say what, how and why it will work.
Let's see how the whole InvoiceItem will look now.

Now we have a class that is easy to read and understand at first glance. Assignments are easy to select, attribute accessors are simple to use.
What else is the possibility of optimizing our code? In most cases, writing tests at the very beginning of learning programming can cause problems due to the lack of necessary knowledge. Time is spent creating fake data. There is nothing terrible in this, but in many cases this leads to the creation of large arrays of difficult to read text. Let's take a look at this.

Oh, damn it. Here, at the very beginning, a new repository is created to store the transaction classes. A total of three, each used for the test, falling into the hash for later use. And for the class that we are going to create, many attributes are required. Each of them has a rather long name and value. What can be improved to make the code look good?
It's simple.

We split each of these hashes with a line break with each new value declaration. In addition, the same method was used as in the optimization of InvoiceTeam. Now you can see all the test data in a rather narrow field of view in the editor without any problems. We can see the key values. If necessary, they can be changed without scrolling back and forth.
A similar strategy can be used when we work with a large number of attributes.

In this case, we do not see the entire code structure, at least in the current viewport. In order to see the attributes, you need to constantly scroll, which is not very convenient. Let's fix this in the same way as we did above, in the hashes example.

The new code is readable - and much more human friendly, so to speak. All attributes and assignments are clearly visible. Possible debugging becomes easier. Something can go wrong, and then find out what does not work and why, it will be difficult if you do not bring the code to a “beautiful” view.
When we write programs, we must not forget: it is important not only that they work correctly, but also that the principle of their functioning was clear to colleagues, if necessary. The code should be logical, divided into paragraphs, sentences and structural sections.
Well, in the end, my favorite Ruby example. Let's consider it.

Let's take each element from animals and apply the capitalize method. It looks good, but even better is that the code can be slightly reduced and made more readable to humans.

This method works in many cases and I recommend using it whenever possible.
In general, the article can be called trivial, but it allows the novice to understand the beauty of the code. That is, the code itself must be not only working, but also understandable - even if the program is written only for itself. If you develop the habit of creating beautiful working code, it can help your professional growth.
Skillbox recommends: