Hey! I work at Joom on the infrastructure team. In my practice as a code reviewer, I regularly encounter the fact that the author does not understand that the reviewer is not a magic black box into which you can throw any changes and get feedback on them. The reviewer, like the author, as a human being, has a number of weaknesses. And the author should (if, of course, he is interested in a quality review), help the reviewer as much as possible.
I want to tell you how the author of the code can simplify the work of the reviewer and thereby increase both the quality of the review and the productivity of the reviewer. This article may well be used in your internal corporate documentation as a guide for preparing changes for review. It, in fact, was compiled from such a guide.
Why do we do a code reviewYou probably know this without me. Therefore, I will tell you about the very basics, without going into details.
Slightly less than the fastest, portable, 64-bit hash function, with decent quality.
Yes, in the air and in the king, about like that. Read on?
Instead of Disclaimer We drop the definition of hash functions along with a detailed listing of properties and requirements for their cryptographic application, assuming that the reader either owns the necessary knowledge minimums, or will make up for them . Also we agree that here and further we mean non-cryptographic (cryptographically non-persistent) hash functions, unless otherwise specified.
I really liked the discussion thread on Quora.com: What is the hardest part about learning to program? All 87 responses I did not read, but liked, I singled out a separate article of 10 items. It's a free retelling of the opinions of many different people. If readers are interested, I will continue.
1. The difference between high standards and their low skillsIn the article "No one talks about it to newcomers" tells about the common problem of people engaged in creative or intellectual work. Programming is a complex subject, and usually for it are capable, ambitious and prone to perfectionism people. At the initial stage, they will not work well. Accustomed to a high bar, they will be upset. The inner voice will constantly whisper: "You never will, it's better to leave this matter." At such moments, think that your self-criticism is a sign of your extraordinary nature, and believe that you will overcome this "incompetent period".
As for the extraordinary advantages of programming, here they are:
Perhaps, the title of this article may be misleading, but the most of those that have been doing the programming and the designing of software products for a long enough will understand, what will be discussed further in this article. In the first place, it is addressed to the independent developers.
Let us ask themselves a few questions. How often do we rewrite the code from a scratch and try to improve it? How often do we change the design of an application during its development? Do we work too long with each method (or function) and try to think through all aspects of its use? Do we think that any programming serves as a lesson and source of experience? Do we try to use something new in the new code in order to develop ourselves? Do we pay more attention to the laconic brevity / beauty of code than the laconic brevity / beauty of applications in general?
If we answered yes on the most of these questions, congratulations - we are suffering from the perfectionism.
How can perfectionism ruin our life?
Let us start with the fact that the ideals do not exist in our world. We have to get used to this idea and try to live with it. There are no resources that will allow to write the perfect application or just the perfect code, whether we like it or not.