Code Daquan (version 2nd) is a very interesting book with both vivid metaphors and occasional exaggerated expressions. In addition, the author may joke from time to time, reading is not boring at all. The following are some interesting examples. This version is slightly deleted. After the book is published, I will expand the content here.
- First, write programs for people, and then for machines.
- Dummies write code that allows computers to understand, while good programmers write code that people can understand. (Martin Fowler)
- Good habits are very important, because most of what programmers do is done unconsciously.
- The Goto labels should be in full uppercase and must start with the same line. It should also contain the programmer's name, home phone number, and credit card number. (Abdul Nizar)
- Think of the person who maintains your program as a mentally ill patient with a severe violent tendency to know your address. (Region name)
- There are two ways to design the software: one is to make the design very simple, it looks obvious there are no defects; the other is to make the design very complex, it seems there are no obvious defects. (C. A. R Hoare)
- It is too hasty to ignore the program errors prompted by the compiler. Turning off the warning function of the compiler is nothing more than a false alarm. Turning off the warning function of the compiler only means that you cannot see the errors, and it does not mean that these errors will disappear, just as if the children close their eyes, they will not make their parents disappear.
- To improve the quality of software through more tests, you just want to lose weight more frequently. (Editor's note: The author does not mean that the test is useless, but does not rely solely on the test .)
- What is the impact of Psychological orientation on debugging? First, it proves the importance of developing good programming habits. Standard Format, appropriate comments, good variables and subprogram naming methods, and other programming style elements all help to build a good foundation for programming. On the basis of this, possible errors will become especially noticeable because of their uniqueness.
- The interactive debugger is an excellent example of a debugger that programmers do not need-It encourages programmers to use random experiments to find errors, rather than conducting System Analysis on the program. At the same time, such tools also give people who are almost not qualified for meticulous programming the opportunity to fill in. (Harlan Mills)
- Smart is not like an aspect of personal character, nor is it true. Coincidentally, there is no close connection between high IQ and excellent programmers.
- The performance of laziness promotes your efforts to reduce the overall cost. When you write labor-saving programs, others will think that these programs are useful, so that you can write instructions so that people will not always ask you. (Larry Wall)
- You may feel tired from eight o'clock A.M. to two o'clock P.M. one day. But you still stick to it, and from two o'clock P.M.. In the next week, you are modifying what you wrote in the last three hours.
- The most important part of effective programming is thinking, which often doesn't seem very busy. If the programmer I work with is always busy, I will think that he is not a good programmer because he has no use of the most valuable tool-his head.
- "We need programmers with more than five years of C programming experience" is a silly statement. If a programmer has not learned C language well for the past one or two years, it makes no sense to add three more years.
- Debugging code is twice as difficult as writing the code for the first time. Therefore, if you have used all your talents when writing code, you will not be able to debug the Code with your own wisdom. (Brian kernighan)
- "This cycle seems to be faulty. It may be an off-by-one error. Let me first write a-1 example. Oh, no. Then I will try to write more than 1. Aha, it seems that the program is working normally. I can announce that the problem is fixed ." -- Randomly modify the code until your code looks to work. This is called "voodoo programming (Wuxi programming )".
- Every team may have such a programmer who will always encounter endless problems: disobedient machines, strange compiler errors, hidden defects of programming languages that will occur only when the circle is full, invalid Data, important changes that have been forgotten, and a crazy editor that cannot properly store programs-How do you describe this behavior. This is "programming by superstition )".
Finally, is mathematics very important to programming? Throughout code Daquan, the author talked about all aspects that affect the quality of software, but * did not say * that the mathematical skills of programmers are an important factor. For programmers, mastering mathematical knowledge is not a required skill. In my opinion, mathematics is not a decisive factor or even an important factor. I have never heard of any software project that fails because of a poor mathematical skills of the developers, or because of lack of mathematics, the quality is low and the bug is high.
First of all, mathematics is a large discipline with many branches. If you think it is important, you must list the knowledge that affects software development. I personally feel that there is very little mathematical knowledge directly used in project development. And if you really want to use it, the proportion of the involved code will not be very large, then one or two people in the entire project team (not necessarily programmers) can be proficient (with encapsulation + abstraction, make it a black box ).
Rather than emphasizing abstract "mathematical knowledge", it is better to emphasize specific "domain knowledge ". Some fields involve some mathematics, such as numerical calculation, circuit analysis, image processing, and signal processing. However, these mathematical knowledge are applied to this field and are encapsulated by domain knowledge. Mathematics is hardly involved in some fields (the premise is that you should not classify all thinking-related items into "Mathematics "), such as digital circuit design, sports competition scoring, and many common software projects (attendance, system tools, websites ). These fields also have their own domain knowledge. If you do not know this knowledge, you cannot write software, but it seems to have nothing to do with mathematics.
All in all, compared to other professional qualities of programmers (curiosity, honesty, communication skills, laziness, good habits, etc.), "mathematical knowledge" cannot be ranked.
PS. I am one of the four translators of this book. I cannot provide you with an electronic version.
