[Reproduced from: http://mindhacks.cn/2009/03/09/first-principles-of-programming/]
Half a year ago, the stackoverflow.com jointly developed by joelonsoftware and codinghorror was launched shortly after, and I rushed over and threw a question:
What do you think is the first principle of programming?
As a practice of my learning principles:
8. To learn a knowledge, you must ask yourself three important questions: 1. What is its essence. 2. What is its first principle. 3. What is its knowledge structure.
Five months have passed, and some people have replied to this question. I have got a lot of interesting answers and can't help translating them to share with you:
1. ObtainAnswers that are most recognized:
Kiss-Keep It Simple Stupid
Dry-Don't repeat yourself
Don't you feel surprised?
Note: The dry principle is easier to understand and practice. However, the kiss principle is straightforward. In fact, it is not so easy to practice, because the definitions of simple and stupid are not consistent and obvious in every scenario, A person's simple may be another person's stupid, and a person's stupid may be another person's unnecessary. Once a standard depends on a specific scenario, it is not that simple. So we often say "it depends ".
2. ObtainThe second answer:
When writing code, imagine that you are the person who will maintain the code in the future.
Someone added this answer:
It is best to imagine that your code will be maintained by an ax-running mental illness.
Another YY said:
In addition, this ax-running mental illness knows where you live. 1
Note: In fact, this principle is also useful in API design:
When writing an API, imagine that you are the person who wants to use this API.
3.Some answers that are not necessarily correct:
First, find out what your problem is!
Identifying a problem is always the first and most important step in solving the problem.
Code is just a tool, not a means.
I don't know how to best solve your problem (Note: requirement, architecture, algorithm, technology selection, Etc ..). Writing 10 thousand pieces of code is also a waste of bits.
Know when it should not be encoded.
(Similar entry: yagni -- "You don't need to write this code !", Coding for your needs, "Write what you need", don't do "smart things", and code for an uncertain future. At the same time, pay attention to modular design, so that the system can be easily expanded in the future when new requirements are added)
Never assume that you already know everything!
No inferences without evidence.
Write again after thinking clearly. Similar entries:If the scheme cannot work in your mind or on paper, writing code still cannot work.
4. Some public answers are likely to follow:
The lazy the better.
Premature optimization is the root cause of all evil.
Do not re-invent the wheel.
What "it can work" is purely nonsense before the test is passed.
Understand your tools.
All are user-oriented.
Use sub-governance and abstraction to solve the coupling between sub-problems.
5.The most humorous answer:
Coffee feed, code output. (Coffee in, code out) 2
Finally, the thread of the entire problem is here.
Footnotes:
- In fact, someone later pointed out that this is a famous saying of Martin Golding []
- See garbage in, garbage out. []