函数
- 函数最多两个入参，过多的话就用对象解构来接收
function({title,length})
-
函数入参不要包括flag 如果入参里有flag且flag下的代码还不一样，则应该把函数拆分成两个
-
避免函数副作用 对象和数组是引用传递，所以作为函数入参时要小心对待。为了避免此类情形，可以使用浅拷贝或者深拷贝等方法克隆一份数据。
-
封装条件语句
function shouldShowSpinner(fsm, listNode) {
return fsm.state === "fetching" && isEmpty(listNode);
}
if (shouldShowSpinner(fsmInstance, listNodeInstance)) {
// ...
}
5.用多态继承替代if条件判断
BAD:
class Person {
getSkinColor(){
switch(this.type){
case "china":return 'yellow';
case "american":return 'white';
}
}
}
GOOD：
class Person{...}
class Chinese extends Person{
getSkinColor(){return 'yellow'}
}
- 不要过度优化
Modern browsers do a lot of optimization under-the-hood at runtime. A lot of times, if you are optimizing then you are just wasting your time. There are good resources for seeing where optimization is lacking. Target those in the meantime, until they are fixed if they can be.
对象和数据结构
- 使用get和set方法，去获取复杂对象的数据。可以方便扩展和调试。
- 设置私有成员 可以防止误删除
类
- 使用es6声明
- 使用方法链 在jQuery和Lodash中就是使用了链式表达，它使您的代码更具表现力且不那么冗长。
class Car {
constructor(make, model, color) {
this.make = make;
this.model = model;
this.color = color;
}
setColor(color) {
this.color = color;
// NOTE: Returning this for chaining
return this;
}
save() {
console.log(this.make, this.model, this.color);
// NOTE: Returning this for chaining
return this;
}
}
const car = new Car("Ford", "F-150", "red").setColor("pink").save();
- 使用组合>继承
正如Gang of Four在(Design Patterns)中所说的那样，您应该尽可能选择组合而不是继承。 使用继承有很多充分的理由，使用组合也有很多充分的理由。 该格言的要点是，如果您的思想本能地倾向于继承，请尝试思考组合是否可以更好地模拟您的问题。 在某些情况下可以。 以下是几种适合使用继承的情形：
- 数据间呈现的是“is-a”情形，而不是“has-a”情形。
"is-a"表达：人类->中国人 "has-a"表达：用户->用户信息
- 需要复用一些基础类
- 希望通过更改基类来对派生类进行全局更改。
SOLID原则
-
S:单一原则
-
O:开闭原则 对扩展开放，对修改关闭
-
L:里氏代换原则
核心思想是：如果S是T的子类型，那么在任何使用T类型的地方，都应该能够使用S类型，而不会引发异常或破坏程序的正确性。
具体来说，遵循里氏代换原则的类之间应该满足以下条件：
- 子类必须能够替代父类： 子类在继承父类时，不应该修改父类原有的行为，而只是对其进行扩展。子类的行为应该与父类一致，以保证在使用子类对象替代父类对象时不会影响程序的正确性。
- 子类可以增加自己的特有行为： 子类可以在不破坏父类行为的前提下，增加自己的特有方法或属性。这样可以实现对父类的扩展，同时保持一致的接口。
- 子类覆写（重写）的方法应该保持协变： 如果子类覆写了父类的方法，那么子类方法的输入参数应该与父类方法一致或更宽松，输出结果应该与父类方法一致或更严格。这确保了子类的方法可以替代父类的方法。
-
I: 接口隔离原则
不应强迫客户端依赖他们不使用的接口。
-
D: 依赖倒置原则
该原则规定了两个基本事项：
- 高层模块不应该依赖于低层模块。 两者都应该依赖于抽象。
- 抽象不应该依赖于细节。 细节应该取决于抽象。
注释
- 只注释具有业务逻辑复杂性的内容
- 不要在代码库中留下注释掉的代码
- 不需要为死区代码写注释，特别是日志注释。使用 git 日志获取历史记录！
- 避免位置标记。让函数和变量名称以及正确的缩进和格式为代码提供视觉结构
引用：
github.com/ryanmcdermo… github.com/petkaantono… en.wikipedia.org/wiki/Design…
