this article is extracted from the first chapter of the code of neatness, which is considered one of the books that programmers must read. But the good books not only give you the tools and technology, more is the thinking process, almost Zen, of course, this book is consistent with this definition. This chapter has the least technical elements and is suitable for people in every field.
read this book for two reasons. First, you’re a programmer; second, you want to be a better programmer. Very well. We need better programmers.
this is a book on how to write a good program. It’s full of code. We need to look at the code in all directions. From the top down, from the bottom up, from the inside out. You’ll know a lot about the code after you’ve read it. And we can also tell the difference between good code and bad code. We’ll learn how to write good code. We’ll also know how to change bad code into good code.
1.1 needs code
some might think that books about code are a bit behind the times – code is no longer a problem; we should focus on models and requirements. Indeed, someone has said that we are approaching the endpoint of the code. Soon, the code will be automatically generated without manual writing. Programmers are useless, because business people can generate programs directly from the protocol.
nonsense! We will not throw away code, because the code showing the details of the requirements. At some level, these details can not be ignored or abstracted, and must be made clear. The extent to which the requirements are explicit to the extent that the machine can be executed is what programming is going to do. And the code is the code.
I expect the language abstraction to continue to improve. I also expect the number of domain specific languages to continue to increase. That would be a good thing. But that doesn’t end the code. In fact, the specification written at a higher level in domain specific language will also be code, and it has to be rigorous, precise, standardized and detailed to allow the machine to understand and execute.
the guys who thought the code was going to disappear would be like looking for a mathematician who didn’t have regular math. They look forward to the possibility of creating a machine some day, and we’ll just have to think about it and use it without a mouth. That machine is able to understand us thoroughly, and only in this way can it translate the vague requirements into perfectly executed procedures and precisely meet the requirements.
, that’s never gonna happen. Even humans, with all their instincts and creativity, fail to produce successful systems that satisfy the customer’s vague feelings. If the requirement specification principles taught us what is good, the return code needs as formal, executable code can be used as a test to use.
remember that the code is indeed that we used to express the needs of.