Download as PDF, PPTX
Uploaded byJingchao Di
Brief principle and principle of coding
The document discusses principles and best practices for coding, including features of good code, principles like DRY and SOLID, and best practices. It covers keeping code readable, maintainable, and reliable. Specific principles mentioned include single responsibility, open/closed, Liskov substitution, interface segregation, and dependency inversion. Programming guidelines like Pythonic and avoiding literals are also listed. The document aims to provide an actionable coding guide rather than just an informational sharing.
Brief principle and principle of coding
- 1. Brief Principle &Practice of Coding @3D 2017-07-18
- 2.
- 4. Agenda ๏ 好代码的特征 ๏ Principle ๏Best Practice
- 5.
- 6.
- 7.
- 8.
- 9. Don't Repeat Yourself ๏杜绝重复信息 ๏ 系统中每⼀一部分，有单⼀一、明确、 权威的代表
- 10. KISS ๏ Keep IsSimple, Stupid ๏ 抓住问题核⼼心 ๏ 避免过度设计/过早优化 ๏ 降低维护成本
- 11. SOLID ๏ Single RepositoryPrinciple - 单⼀一功能原则 ๏ Open-Close Principle - 开闭原则 ๏ Liskov Substitution Principle - ⾥里里⽒氏替换原则 ๏ Interface-Segregation Principle - 接⼝口隔离原则 ๏ Dependency inversion Principle - 依赖反转原 则
- 12.
- 13. Open-Close Principle ๏ 对扩展是开放的 ๏对修改是bu变的
- 14.
- 15. Interface-Segregation Principle ๏ 调⽤用者应当依赖仅仅它需要接⼝口 ๏ 将⼤大接⼝口拆为多个⼩小接⼝口 ๏Readable / Closable / Iterable
- 16.
- 17.
- 18.
- 19. Beautiful is betterthan ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
- 20. ๏ 美丽优于丑陋陋，明讲好过暗喻 ๏ 简洁者为上，复杂者次之，繁涩者为下 ๏特例例不不能打破原则 ๏ 不不要忽略略错误提示 ๏ 模棱两可时候，不不要猜测 ๏ 使⽤用⼀一种明确的⽅方法，最好是⼀一种公认的
- 21.
- 23.
- 24. 最佳实践包含哪些？ ๏ 标准的命名 ๏ 标准的结构 ๏标准的业务流程
- 25.
- 26.
- 27.
- 28.
- 29.
- 30. 尽⼒力力解决 IDE 提示的所 有ERROR / Warning
- 31.
- 32.
- 34.
- 35. Reference ๏ SOLID, DRY,SLAP design principles ๏ Single Level of Abstraction (SLA) ๏ SOLID (⾯面向对象设计) - Wikipedia ๏ 敏敏捷软件开发 - Wikipedia ๏ ⼀一次且仅⼀一次 - Wikipedia ๏ KISS principle - Wikipedia