Facebook软件工程师的10条clean code原则

避免if嵌套

// 糟糕的

function processUser(user) {
  if (user !== null) {
    if (user.hasSubscription) {
      if (user.age >= 18) {
        showFullVersion();
      } else {
        showChildrenVersion();
      }
    } else {
      throw new Error("User needs a subscription to access the content.");
    }
  } else {
    throw new Error("No user found");
  }
}

// 更好的

function processUser(user) {
  if (user !== null) {
    throw new Error("No user found");
  }

  if (user.hasSubscription) {
    throw new Error("User needs a subscription to access the content.");
  }

  if (user.age >= 18) {
    showFullVersion();
    return;
  }

  showChildrenVersion();
}

代码逻辑更清晰易读，并且采用了快速失败的原则（后面会提到）。

避免使用有歧义的命名

// 糟糕的

const MIN_PASSWORD = 6;

const checkPassword = (password) => {
  return password.length >= MIN_PASSWORD;
}

// 更好的

const MIN_PASSWORD_LENGTH = 6;

const isPasswordLongEnough = (password) => {
  return password.length >= MIN_PASSWORD_LENGTH;
}

变量和函数的命名意义更明确，其中包含了有价值的信息。

避免过度注释

// 糟糕的

// Function to check if a number is prime
function isPrime(number) {
  // Check if number is less than 2
  if (number < 2) {
    // If less than 2, not a prime number
    return false;
  }

  // At least 1 divisor must but less than square root, so we can stop there
  for (let i = 2; i <= Math.sqrt(number); i++) {
    // Check if number is divisible by i
    if (number % i === 0) {
      // If divisible, number is not prime
      return false;
    }
  }
 
  // After all checks, is not divisible by any i, number is prime
  return true;
}

// 更好的

function isPrime(number) {
  if (number < 2) {
    return false;
  }

  // At least 1 divisor must but less than square root, so we can stop there
  for (let i = 2; i <= Math.sqrt(number); i++) {
    if (number % i === 0) {
      return false;
    }
  }

  return true;
}

去掉了啰嗦的废话注释，保留关键代码的注释，减少了给阅读者的干扰。

避免不一致的代码格式

// 糟糕的

const name = "Conner";
let age=26;

function getUserInfo() {
console.log("User Info:");
    console.log('Name:' + name)
  console.log(`Age: ${age}`);
}

// 更好的

const name = "Conner";
const age = 26;

function getUserInfo() {
  console.log("User Info:");
  console.log(`Name:${name}`);
  console.log(`Age: ${age}`);
}

始终如一的代码风格是基本要求。（其中将let换成了const，这是一条最佳实践，只在你确实需要重写变量值的时候用let，否则一律用const）

避免重复的代码

// 糟糕的

function logLogin() {
  console.log('User logged in at ' + new Date())
}

function logLogout() {
  console.log('User logged out at ' + new Date())
}

function logSignUp() {
  console.log('User singed up at ' + new Date())
}

// 更好的

function logAction(action) {
  console.log(`User ${action} at ${new Date()}`)
}

更好维护，更易于拓展。

尽快失败原则

// 糟糕的

function getUppercaseInput(input) {
  const result = input?.toUpperCase?.();

  if (typeof input !== 'string' || input.trim() === '') {
    throw new Error('Invalid input')
  }

  return result
}

// 更好的

function getUppercaseInput(input) {
  if (typeof input !== "string" || input.trim() === "") {
    throw new Error("Invalid input");
  }

  const result = input.toUpperCase();

  return result;
}

当输入不满足要求时，就应该第一时间结束，因为它最终都无法执行下去。而不是走到最后才停止，做一堆无用功。

避免魔法变量

// 糟糕的

let price = 10;

if (transactionType === 1) {
  price *= 1.1
}

// 更好的

const TAXABLE_TRANSACTION_TYPE = 1;
const TAX_MULTIPLE = 1.1;

let price = 10;
if (transactionType === TAXABLE_TRANSACTION_TYPE) {
  price *= TAX_MULTIPLE;
}

没人会喜欢那些让人摸不着头脑的魔法变量吧？

避免副作用

// 糟糕的

let area = 0;

function calculateAndUpdateArea(radius) {
  const newArea = Math.PI * radius * radius;
  area = newArea;
  return newArea;
}

// 更好的

let area = 0;

function calculateArea(radius) {
  return Math.PI * radius * radius;
}

area = calculateArea(5)

避免副作用，让你免于遭受莫名其妙的bug。而且函数负责了过多的职责，计算和更新，从函数名上就可以看出来。

避免过多职责

// 糟糕的

const numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

const result = numbers.reduce(
  (acc, value) => (value & 1 ? [...acc, value * value] : acc),
  []
);

// 更好的

const numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

const result = numbers
  .filter((value) => value % 2 === 0)
  .map((value) => value * value);

过多的职责，提高了修改时引入bug的风险，阅读也更困难。说单一职责是软件领域最重要的一条原则应该没人有异议。

不要过早优化

只有当性能成为你程序的瓶颈的时候，你才需要进行优化。否则你的优化代码将成为你和维护者的负担。

内容来源

https://www.youtube.com/watch?v=wSDyiEjhp8k