丙午🐎年

第 4 章 表达式和基本语句

【规则 4-1-1 】如果代码行中的运算符比较多，用括号确定表达式的操作顺序，避免使用默认的优先级

1. 加了增强理解, 即使看上去加了等于没加
2. 加了可避免一些不希望使用默认的优先级的行为

【规则 4-2-2 】不要有多用途的复合表达式。
例如：
d = (a = b + c) + r ;
该表达式既求 a 值又求 d 值。应该拆分为两个独立的语句：
a = b + c;
d = a + r;

C语言程序设计（下）——从 C 到 C

来不及了, 报名下一次吧
https://www.icourse163.org/course/0809CAU007-432001

C++ 教程 | 菜鸟教程

1
2
3
4
5

cout<<1<<'\t'<<1<<endl;
cout<<1234<<'\t'<<1234<<endl;
cout<<1234567<<'\t'<<1234567<<endl;
cout<<12345678<<'\t'<<12345678<<endl;
cout<<123456789<<'\t'<<123456789<<endl;

目的：为什么要学习设计模式

提高复杂代码的设计和开发能力。让读源码、学框架事半功倍。

为你的职场发展做铺垫。为了应付面试, 更有竞争力。

从哪些维度评判代码质量的好坏？如何具备写出高质量代码的能力？

最常用到几个评判代码质量的标准是：可维护性、可读性、可扩展性、灵活性、简洁性、可复用性、可测试性。其中，可维护性、可读性、可扩展性又是提到最多的、最重要的三个评价标准。

要写出高质量代码，我们就需要掌握一些更加细化、更加能落地的编程方法论，这就包含面向对象设计思想、设计原则、设计模式、编码规范、重构技巧等等，这也是我们后面课程学习的重点。

面向对象、设计原则、设计模式、编程规范、重构，这五者有何关系？

需要透彻理解并且掌握，如何应用下面这样几个常用的设计原则。

• SOLID 原则
• SRP 单一职责原则
• OCP 开闭原则
• LSP 里式替换原则
• ISP 接口隔离原则
• DIP 依赖倒置原则
  阅读全文 »

设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目中合理地运用设计模式可以完美地解决很多问题，每种模式在现实中都有相应的原理来与之对应，每种模式都描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是设计模式能被广泛应用的原因。

设计模式的六大原则

单一职责原则 Single Responsibility Principle（SRP）

单一职责原则的英文是 Single Responsibility Principle，缩写为 SRP。这个原则的英文描述是这样的：A class or module should have a single responsibility。如果我们把它翻译成中文，那就是：一个类或者模块只负责完成一个职责（或者功能）。

判定一个类的职责是否够单一。而且，我个人觉得，下面这几条判断原则，比起很主观地去思考类是否职责单一，要更有指导意义、更具有可执行性：

• 类中的代码行数、函数或属性过多，会影响代码的可读性和可维护性，我们就需要考虑对类进行拆分；
• 类依赖的其他类过多，或者依赖类的其他类过多，不符合高内聚、低耦合的设计思想，我们就需要考虑对类进行拆分；
• 私有方法过多，我们就要考虑能否将私有方法独立到新的类中，设置为 public 方法，供更多的类使用，从而提高代码的复用性；
• 比较难给类起一个合适名字，很难用一个业务名词概括，或者只能用一些笼统的 Manager、Context 之类的词语来命名，这就说明类的职责定义得可能不够清晰；
• 类中大量的方法都是集中操作类中的某几个属性，比如，在 UserInfo 例子中，如果一半的方法都是在操作 address 信息，那就可以考虑将这几个属性和对应的方法拆分出来。

如何理解 KISS 原则

KISS 原则的英文描述有好几个版本，比如下面这几个。

• Keep It Simple and Stupid.
• Keep It Short and Simple.
• Keep It Simple and Straightforward.

翻译过来意思就是“尽量保持简单”。

如何写出满足 KISS 原则的代码？

• 不要使用同事可能不懂的技术来实现代码。比如前面例子中的正则表达式，还有一些编程语言中过于高级的语法等。
• 不要重复造轮子，要善于使用已经有的工具类库。经验证明，自己去实现这些类库，出 bug 的概率会更高，维护的成本也比较高。
• 不要过度优化。不要过度使用一些奇技淫巧（比如，位运算代替算术运算、复杂的条件语句代替 if-else、使用一些过于底层的函数等）来优化代码，牺牲代码的可读性。