函数

函数参数 (两个以下最理想)

限制函数参数的个数是非常重要的, 因为这样将使你的函数容易进行测试。 一旦超过三个参数将会导致组
合爆炸, 因为你不得不编写大量针对每个参数的测试用例。

没有参数是最理想的, 一个或者两个参数也是可以的, 三个参数应该避免, 超过三个应该被重构。 通常,
如果你有一个超过两个函数的参数, 那就意味着你的函数尝试做太多的事情。 如果不是, 多数情况下一个
更高级对象可能会满足需求。

由于 JavaScript 允许我们不定义类型/模板就可以创建对象, 当你发现你自己需要大量的参数时, 你
可以使用一个对象。

不好的:

  1. function createMenu(title, body, buttonText, cancellable) {
  2. // ...
  3. }

好的:

  1. const menuConfig = {
  2. title: 'Foo',
  3. body: 'Bar',
  4. buttonText: 'Baz',
  5. cancellable: true
  6. };
  7. function createMenu(config) {
  8. // ...
  9. }

函数应当只做一件事情

这是软件工程中最重要的一条规则, 当函数需要做更多的事情时, 它们将会更难进行编写、 测试和推理。
当你能将一个函数隔离到只有一个动作, 他们将能够被容易的进行重构并且你的代码将会更容易阅读。 如
果你严格遵守本指南中的这一条, 你将会领先于许多开发者。

不好的:

  1. function emailClients(clients) {
  2. clients.forEach((client) => {
  3. const clientRecord = database.lookup(client);
  4. if (clientRecord.isActive()) {
  5. email(client);
  6. }
  7. });
  8. }

好的:

  1. function emailClients(clients) {
  2. clients
  3. .filter(isClientActive)
  4. .forEach(email);
  5. }
  6. function isClientActive(client) {
  7. const clientRecord = database.lookup(client);
  8. return clientRecord.isActive();
  9. }

函数名称应该说明它要做什么

不好的:

  1. function addToDate(date, month) {
  2. // ...
  3. }
  4. const date = new Date();
  5. // 很难从函数名看出加了什么
  6. addToDate(date, 1);

好的:

  1. function addMonthToDate(month, date) {
  2. // ...
  3. }
  4. const date = new Date();
  5. addMonthToDate(1, date);

函数应该只有一个抽象级别

当在你的函数中有多于一个抽象级别时, 你的函数通常做了太多事情。 拆分函数将会提升重用性和测试性。

不好的:

  1. function parseBetterJSAlternative(code) {
  2. const REGEXES = [
  3. // ...
  4. ];
  5. const statements = code.split(' ');
  6. const tokens = [];
  7. REGEXES.forEach((REGEX) => {
  8. statements.forEach((statement) => {
  9. // ...
  10. });
  11. });
  12. const ast = [];
  13. tokens.forEach((token) => {
  14. // lex...
  15. });
  16. ast.forEach((node) => {
  17. // parse...
  18. });
  19. }

好的:

  1. function tokenize(code) {
  2. const REGEXES = [
  3. // ...
  4. ];
  5. const statements = code.split(' ');
  6. const tokens = [];
  7. REGEXES.forEach((REGEX) => {
  8. statements.forEach((statement) => {
  9. tokens.push( /* ... */ );
  10. });
  11. });
  12. return tokens;
  13. }
  14. function lexer(tokens) {
  15. const ast = [];
  16. tokens.forEach((token) => {
  17. ast.push( /* ... */ );
  18. });
  19. return ast;
  20. }
  21. function parseBetterJSAlternative(code) {
  22. const tokens = tokenize(code);
  23. const ast = lexer(tokens);
  24. ast.forEach((node) => {
  25. // parse...
  26. });
  27. }

移除冗余代码

竭尽你的全力去避免冗余代码。 冗余代码是不好的, 因为它意味着当你需要修改一些逻辑时会有多个地方
需要修改。

想象一下你在经营一家餐馆, 你需要记录所有的库存西红柿, 洋葱, 大蒜, 各种香料等等。 如果你有多
个记录列表, 当你用西红柿做一道菜时你得更新多个列表。 如果你只有一个列表, 就只有一个地方需要更
新!

你有冗余代码通常是因为你有两个或多个稍微不同的东西, 它们共享大部分, 但是它们的不同之处迫使你使
用两个或更多独立的函数来处理大部分相同的东西。 移除冗余代码意味着创建一个可以处理这些不同之处的
抽象的函数/模块/类。

让这个抽象正确是关键的, 这是为什么要你遵循 Classes 那一章的 SOLID 的原因。 不好的抽象比冗
余代码更差, 所以要谨慎行事。 既然已经这么说了, 如果你能够做出一个好的抽象, 才去做。 不要重复
你自己, 否则你会发现当你要修改一个东西时时刻需要修改多个地方。

不好的:

  1. function showDeveloperList(developers) {
  2. developers.forEach((developer) => {
  3. const expectedSalary = developer.calculateExpectedSalary();
  4. const experience = developer.getExperience();
  5. const githubLink = developer.getGithubLink();
  6. const data = {
  7. expectedSalary,
  8. experience,
  9. githubLink
  10. };
  11. render(data);
  12. });
  13. }
  14. function showManagerList(managers) {
  15. managers.forEach((manager) => {
  16. const expectedSalary = manager.calculateExpectedSalary();
  17. const experience = manager.getExperience();
  18. const portfolio = manager.getMBAProjects();
  19. const data = {
  20. expectedSalary,
  21. experience,
  22. portfolio
  23. };
  24. render(data);
  25. });
  26. }

好的:

  1. function showList(employees) {
  2. employees.forEach((employee) => {
  3. const expectedSalary = employee.calculateExpectedSalary();
  4. const experience = employee.getExperience();
  5. let portfolio = employee.getGithubLink();
  6. if (employee.type === 'manager') {
  7. portfolio = employee.getMBAProjects();
  8. }
  9. const data = {
  10. expectedSalary,
  11. experience,
  12. portfolio
  13. };
  14. render(data);
  15. });
  16. }

使用 Object.assign 设置默认对象

不好的:

  1. const menuConfig = {
  2. title: null,
  3. body: 'Bar',
  4. buttonText: null,
  5. cancellable: true
  6. };
  7. function createMenu(config) {
  8. config.title = config.title || 'Foo';
  9. config.body = config.body || 'Bar';
  10. config.buttonText = config.buttonText || 'Baz';
  11. config.cancellable = config.cancellable === undefined ? config.cancellable : true;
  12. }
  13. createMenu(menuConfig);

好的:

  1. const menuConfig = {
  2. title: 'Order',
  3. // User did not include 'body' key
  4. buttonText: 'Send',
  5. cancellable: true
  6. };
  7. function createMenu(config) {
  8. config = Object.assign({
  9. title: 'Foo',
  10. body: 'Bar',
  11. buttonText: 'Baz',
  12. cancellable: true
  13. }, config);
  14. // config now equals: {title: "Order", body: "Bar", buttonText: "Send", cancellable: true}
  15. // ...
  16. }
  17. createMenu(menuConfig);

不要使用标记位做为函数参数

标记位是告诉你的用户这个函数做了不只一件事情。 函数应该只做一件事情。 如果你的函数因为一个布尔值
出现不同的代码路径, 请拆分它们。

不好的:

  1. function createFile(name, temp) {
  2. if (temp) {
  3. fs.create(`./temp/${name}`);
  4. } else {
  5. fs.create(name);
  6. }
  7. }

好的:

  1. function createFile(name) {
  2. fs.create(name);
  3. }
  4. function createTempFile(name) {
  5. createFile(`./temp/${name}`);
  6. }

避免副作用

如果一个函数做了除接受一个值然后返回一个值或多个值之外的任何事情, 它将会产生副作用, 它可能是
写入一个文件, 修改一个全局变量, 或者意外的把你所有的钱连接到一个陌生人那里。

现在在你的程序中确实偶尔需要副作用, 就像上面的代码, 你也许需要写入到一个文件, 你需要做的是集
中化你要做的事情, 不要让多个函数或者类写入一个特定的文件, 用一个服务来实现它, 一个并且只有一
个。

重点是避免这些常见的易犯的错误, 比如在对象之间共享状态而不使用任何结构, 使用任何地方都可以写入
的可变的数据类型, 没有集中化导致副作用。 如果你能做到这些, 那么你将会比其它的码农大军更加幸福。

不好的:

  1. // Global variable referenced by following function.
  2. // 全局变量被下面的函数引用
  3. // If we had another function that used this name, now it'd be an array and it
  4. // could break it.
  5. // 如果我们有另一个函数使用这个 name , 现在它应该是一个数组, 这可能会出现错误。
  6. let name = 'Ryan McDermott';
  7. function splitIntoFirstAndLastName() {
  8. name = name.split(' ');
  9. }
  10. splitIntoFirstAndLastName();
  11. console.log(name); // ['Ryan', 'McDermott'];

好的:

  1. function splitIntoFirstAndLastName(name) {
  2. return name.split(' ');
  3. }
  4. const name = 'Ryan McDermott';
  5. const newName = splitIntoFirstAndLastName(name);
  6. console.log(name); // 'Ryan McDermott';
  7. console.log(newName); // ['Ryan', 'McDermott'];

不要写入全局函数

污染全局在 JavaScript 中是一个不好的做法, 因为你可能会和另外一个类库冲突, 你的 API 的用户
可能不够聪明, 直到他们得到在生产环境得到一个异常。 让我们来考虑这样一个例子: 假设你要扩展
JavaScript 的 原生 Array , 添加一个可以显示两个数组的不同之处的 diff 方法, 你可以在
Array.prototype 中写一个新的方法, 但是它可能会和尝试做相同事情的其它类库发生冲突。 如果有
另外一个类库仅仅使用 diff 方法来查找数组的第一个元素和最后一个元素之间的不同之处呢? 这就是
为什么使用 ES2015/ES6 的类是一个更好的做法的原因, 只要简单的扩展全局的 Array 即可。

不好的:

  1. Array.prototype.diff = function diff(comparisonArray) {
  2. const hash = new Set(comparisonArray);
  3. return this.filter(elem => !hash.has(elem));
  4. };

好的:

  1. class SuperArray extends Array {
  2. diff(comparisonArray) {
  3. const hash = new Set(comparisonArray);
  4. return this.filter(elem => !hash.has(elem));
  5. }
  6. }

函数式编程优于指令式编程

JavaScript 不是 Haskell 那种方式的函数式语言, 但是它有它的函数式风格。 函数式语言更加简洁
并且更容易进行测试, 当你可以使用函数式编程风格时请尽情使用。

不好的:

  1. const programmerOutput = [
  2. {
  3. name: 'Uncle Bobby',
  4. linesOfCode: 500
  5. }, {
  6. name: 'Suzie Q',
  7. linesOfCode: 1500
  8. }, {
  9. name: 'Jimmy Gosling',
  10. linesOfCode: 150
  11. }, {
  12. name: 'Gracie Hopper',
  13. linesOfCode: 1000
  14. }
  15. ];
  16. let totalOutput = 0;
  17. for (let i = 0; i < programmerOutput.length; i++) {
  18. totalOutput += programmerOutput[i].linesOfCode;
  19. }

好的:

  1. const programmerOutput = [
  2. {
  3. name: 'Uncle Bobby',
  4. linesOfCode: 500
  5. }, {
  6. name: 'Suzie Q',
  7. linesOfCode: 1500
  8. }, {
  9. name: 'Jimmy Gosling',
  10. linesOfCode: 150
  11. }, {
  12. name: 'Gracie Hopper',
  13. linesOfCode: 1000
  14. }
  15. ];
  16. const totalOutput = programmerOutput
  17. .map((programmer) => programmer.linesOfCode)
  18. .reduce((acc, linesOfCode) => acc + linesOfCode, 0);

封装条件语句

不好的:

  1. if (fsm.state === 'fetching' && isEmpty(listNode)) {
  2. // ...
  3. }

好的:

  1. function shouldShowSpinner(fsm, listNode) {
  2. return fsm.state === 'fetching' && isEmpty(listNode);
  3. }
  4. if (shouldShowSpinner(fsmInstance, listNodeInstance)) {
  5. // ...
  6. }

避免负面条件

不好的:

  1. function isDOMNodeNotPresent(node) {
  2. // ...
  3. }
  4. if (!isDOMNodeNotPresent(node)) {
  5. // ...
  6. }

好的:

  1. function isDOMNodePresent(node) {
  2. // ...
  3. }
  4. if (isDOMNodePresent(node)) {
  5. // ...
  6. }

避免条件语句

这看起来似乎是一个不可能的任务。 第一次听到这个时, 多数人会说: “没有 if 语句还能期望我干
啥呢”, 答案是多数情况下你可以使用多态来完成同样的任务。 第二个问题通常是 “好了, 那么做很棒,
但是我为什么想要那样做呢”, 答案是我们学到的上一条代码整洁之道的理念: 一个函数应当只做一件事情。
当你有使用 if 语句的类/函数是, 你在告诉你的用户你的函数做了不止一件事情。 记住: 只做一件
事情。

不好的:

  1. class Airplane {
  2. // ...
  3. getCruisingAltitude() {
  4. switch (this.type) {
  5. case '777':
  6. return this.getMaxAltitude() - this.getPassengerCount();
  7. case 'Air Force One':
  8. return this.getMaxAltitude();
  9. case 'Cessna':
  10. return this.getMaxAltitude() - this.getFuelExpenditure();
  11. }
  12. }
  13. }

好的:

  1. class Airplane {
  2. // ...
  3. }
  4. class Boeing777 extends Airplane {
  5. // ...
  6. getCruisingAltitude() {
  7. return this.getMaxAltitude() - this.getPassengerCount();
  8. }
  9. }
  10. class AirForceOne extends Airplane {
  11. // ...
  12. getCruisingAltitude() {
  13. return this.getMaxAltitude();
  14. }
  15. }
  16. class Cessna extends Airplane {
  17. // ...
  18. getCruisingAltitude() {
  19. return this.getMaxAltitude() - this.getFuelExpenditure();
  20. }
  21. }

避免类型检查 (part 1)

JavaScript 是无类型的, 这意味着你的函数能接受任何类型的参数。 但是有时又会被这种自由咬伤,
于是又尝试在你的函数中做类型检查。 有很多种方式来避免这个, 第一个要考虑的是一致的 API 。

不好的:

  1. function travelToTexas(vehicle) {
  2. if (vehicle instanceof Bicycle) {
  3. vehicle.peddle(this.currentLocation, new Location('texas'));
  4. } else if (vehicle instanceof Car) {
  5. vehicle.drive(this.currentLocation, new Location('texas'));
  6. }
  7. }

好的:

  1. function travelToTexas(vehicle) {
  2. vehicle.move(this.currentLocation, new Location('texas'));
  3. }

避免类型检查 (part 2)

如果你使用原始的字符串、 整数和数组, 并且你不能使用多态, 但是你依然感觉到有类型检查的需要,
你应该考虑使用 TypeScript 。 它是一个常规 JavaScript 的优秀的替代品, 因为它在标准的 JavaScript
语法之上为你提供静态类型。 对常规 JavaScript 做人工类型检查的问题是需要大量的冗词来仿造类型安
全而不缺失可读性。 保持你的 JavaScript 简洁, 编写良好的测试, 并有良好的代码审阅, 否则使用
TypeScript (就像我说的, 它是一个伟大的替代品)来完成这些。

不好的:

  1. function combine(val1, val2) {
  2. if (typeof val1 === 'number' && typeof val2 === 'number' ||
  3. typeof val1 === 'string' && typeof val2 === 'string') {
  4. return val1 + val2;
  5. }
  6. throw new Error('Must be of type String or Number');
  7. }

好的:

  1. function combine(val1, val2) {
  2. return val1 + val2;
  3. }

不要过度优化

现代化浏览器运行时在幕后做大量的优化, 在大多数的时间, 做优化就是在浪费你的时间。 这些是好的
资源
, 用来
查看那些地方需要优化。 为这些而优化, 直到他们被修正。

不好的:

  1. // On old browsers, each iteration with uncached `list.length` would be costly
  2. // because of `list.length` recomputation. In modern browsers, this is optimized.
  3. // 在旧的浏览器上, 每次循环 `list.length` 都没有被缓存, 会导致不必要的开销, 因为要重新计
  4. // 算 `list.length` 。 在现代化浏览器上, 这个已经被优化了。
  5. for (let i = 0, len = list.length; i < len; i++) {
  6. // ...
  7. }

好的:

  1. for (let i = 0; i < list.length; i++) {
  2. // ...
  3. }

移除僵尸代码

僵死代码和冗余代码同样糟糕。 没有理由在代码库中保存它。 如果它不会被调用, 就删掉它。 当你需要
它时, 它依然保存在版本历史记录中。

不好的:

  1. function oldRequestModule(url) {
  2. // ...
  3. }
  4. function newRequestModule(url) {
  5. // ...
  6. }
  7. const req = newRequestModule;
  8. inventoryTracker('apples', req, 'www.inventory-awesome.io');

好的:

  1. function newRequestModule(url) {
  2. // ...
  3. }
  4. const req = newRequestModule;
  5. inventoryTracker('apples', req, 'www.inventory-awesome.io');