These best programming practices and development guidelines in this article are the experiences of great programmers. Tim Oxley has collected these best practices from the internet and put them on Github for others to review and supplement. Hopefully these best practices will bring some help to your development efforts.
1. Don't build large
applications The secret to building large applications is "don't build large applications", which is to split your application into several small applications, and then assemble these testable small applications together. - Justin Meyer, JavaScript MVC author
2. Focus on project quality
When I hear "running code in a hurry", I probably don't use these applications because they gradually lose the ability to be iterable. -Avdi Grimm
3.
Don't write code "Don't write code" is the most important rule every developer needs to learn. There is a lot of duplication, crappy code (across projects), and in many cases developers don't even look closely at what's around, they just write code.
4. Aim for reducing the amount of code in
the product I hate code and I want to have as little code as possible in our product. --Jack Diederich
5. Keep Reliance Minimal
The classic adage "don't reinvent the wheel" doesn't apply to the wheels at the locomotive (the heart of the project).
6. Stop writing classes
"this shouldn't be a class", especially if the class has two methods and one of them is a constructor. Anytime you see this, you should probably just write a function. —Jack Diederich
7. Forget about new features, do the same thing better
What developers tend to overlook and what users are usually more concerned about is the performance and usability of the most commonly used functions in an application. - Tim Anderson
8. Reinventing the wheel
Inventing your own wheel gives you a deeper understanding of how the wheel works and how you can do it better.
9. Do the easy things, not the hard things
- Simple is better than complex
- Complex is better than complicated
- Sequential is better than embedding
- Readability should be valued
- If your code implementation is hard to explain, this is not a good implementation
10. Rewrite > Refactor
If you are changing more than 25% of a class or method, you can consider rewriting and your code will be cleaner.
11. Refactor > Rewrite
Common excuses for rewriting a project:
- code sucks
- We are smarter now
- We picked the wrong platform/language
- it always takes longer than you expect
- The market is constantly changing
- Existing customers will become frustrated
- Refactoring can also clean up code
- You can't control the rewritten code, it ends up controlling you
You have to admit from the start that you don't know how the project will grow. Once you admit it all, you start designing systems defensively...you should spend most of your time thinking about interfaces, not implementations. —Nicholas Zakas, author of High-Performance JavaScript Websites
13. Avoid code smells (meaning potential problems in your code)
14. Write unit tests
Every programmer knows they should write tests for their code, but few do this way. Asking "why not?" usually responds with "I'm too busy." This can quickly turn into a vicious circle - the more stressed (busy) you are, the less tests you write, Your code will also become less stable and your productivity will become less and less. As a result, you are more stressed (busier at work). It is because of this vicious circle that programmers' enthusiasm for coding decreases. We've found that sometimes a simple testing framework can make a big difference.
(no unit tests) you're not refactoring, you're just changing a bunch of shit. - Hamlet D'Arcy
15. Test Driven Development & Inversion of Control
Even if your code doesn't need to be tested, you should write testable code. IoC (Inversion of Control) can do this for you. Try to inject test-friendly dependencies or mock instances at test time and isolate the unit under test.
16. Avoid mixing object creation with application logic
17. Avoid creating technical debt
While immature code can work and customers are perfectly fine with it, technical debt at the end will tire you out and the entire workgroup It's also possible to get stuck in place with this technical debt.
18. Premature optimization is the root of evil
Some programmers waste a lot of time thinking or worrying about the speed of non-critical parts of the program, and their attempts have the potential to negatively impact the eventual debugging and maintenance. We should forget about small efficiencies and tell ourselves that "premature optimization is the root of evil" 97% of the time, but we must not miss optimization opportunities in the critical 3%.
19. Plan, plan, plan
Doing the right thing the first time is much less expensive than redoing it later, and the sooner you find a solution, the less expensive it is.
If the temple is considered a winner without a battle, it should be considered a lot; if a temple is not considered a victory without a battle, it should be considered as a small number. More calculation wins less calculation, and in the case of no calculation! I look at it this way and see the winner. - Sun Tzu's art of war
plan is useless, planning is priceless. - Winston Churchill
20. A Learning Programming Team
Even if the programmers on a team are mediocre and inexperienced, if they all write code for the benefit of the team, it is possible to make a great team. It all depends on whether the team realizes that their job is just to code or make coding and learning their primary goal. ——Reginald Braithwaite
21. Continuous evaluation and improvement of
software design is an iterative process. It is impossible to consider everything at the beginning, and it needs to be continuously improved through experience in the subsequent process. And typically, very few software projects are completed exactly as expected, and as the project progresses, the expectations for the project decline.
22. What is Architecture What does
your project architecture reflect? Is it a healthcare system, an accounting system, an inventory management system, or is it rails, spring/hibernate, ASP?
The architecture of a software product should make it easy for everyone to understand what the product is meant to achieve, and the architecture of a system should reflect the use cases of the system rather than the framework it uses. Architecture isn't (or shouldn't be) about frameworks. Architecture should not be backed by a framework. A framework is a tool to use, not an architecture to conform to. If your architecture is framework based, it cannot be based on your use case. —Uncle Bob Martin, author of Screaming Architecture
23. X-Windows System Design Principles
- No need to add new functionality unless a truly complete application cannot be done without it
- Deciding what a system isn't is as important as deciding what it is. You can't meet the needs of everyone in the world, and it's good practice to make the system scalable in an upwardly compatible way to be able to meet additional needs.
- Worse than generalizing from an example, there is no generalizable example.
- If you don't fully understand a problem, it's best not to offer any solutions.
- If 10% of the work is expected to be done with 90% of the effort, there should be an easier solution.
- Avoid complexity as much as possible
- Provide mechanisms rather than policies, and in practice put user-side policies in the hands of users.
- Modularity Principle: Write simple modules to connect them with a clear interface.
- Clarity Criterion: Clarity takes precedence over ingenuity.
- Composition Guidelines: Design programs that can be linked with other programs.
- Separation principle: separate policy and mechanism; separate interface and engine.
- The Simplicity Principle: Design for simplicity and only add complexity when absolutely necessary.
- Thrift rule: Write large programs only after they have been clarified by prototypes.
- Transparency Guidelines: Visibility of the design makes inspection and debugging easier.
- Robustness guidelines: Robustness is the child of transparency and simplicity.
- Representation Criterion: Pack knowledge into data, program logic can be clumsy and robust.
- Principle of Least Surprise: In interface design, always follow the principle of least surprise (always do something surprising).
- Silence Criterion: If a program has no significant output, it should remain silent.
- Repair guideline: If you must make a mistake, do it as loudly and quickly as possible.
- Economy Rule: Programmer time is expensive when compared to machine time.
- Generation Guidelines: Avoid manual programming, and if possible, write programs that write programs.
- Optimization guidelines: build a prototype before polishing, make it work before you optimize.
- Diversity Code: Be suspicious of all claims that "there's only so much".
- Scalability Principle: Design for the future, because it tends to come sooner than you think.
Enterprise-level project combat (with source code) address :http://zz563143188.iteye.com/blog/1825168
Collect five years of development data download address : http://pan.baidu.com/share/home?uk=4076915866&view=shareEnglish original text: Programming Best Practices Tidbits