mkimq

屎山代码风格指南

强推《屎山代码风格指南》，github 开源地址：点击进入open in new window

对标谷歌《JavaScript 风格指南》，地址：点击进入open in new window

规则

以混淆方式命名变量

正面例子

// 这是一种好的方式
let a = 10

反面例子

// 这是一种比较糟糕的方式
let age = 20

混合命名

正面例子

// 这是一种好的方式
let wWidth = 640
let w_width = 640

反面例子

// 这是一种糟糕的方式
let windowWidth = 640
let windowHeight = 480

不要写注释

正面例子

// 这是一种好的方式
const cdr = 700

反面例子

// 700ms的数量是根据UX A/B测试结果进行经验计算的。
// @查看: <详细解释700的一个链接>
const callbackDebounceRate = 700

非母语注释

如果你手贱，确实想写注释，你已经违背了规则 3，在这种情况下，规则 4 一定要遵守，写注释用非母语，提升别人看注释的门槛，例如：你的母语是中文，你写注释就用法语或者俄语

正面例子

// 这是一种好的方式
// Закриваємо модальне віконечко при виникненні помилки.
toggleModal(false)

反面例子

// 这是一种比较糟糕的方式
// 隐藏错误弹窗
toggleModal(false)

尽可能把代码写成一行

把代码写在一行才显得更牛逼,别人写 20 行，你一行就搞定了

正面例子

// 这是一种好的方式
document.location.search.replace(/(^\?)/,'').split('&').reduce(function(o,n){n=n.split('=');o[n[0]]=n[1];return o},{})

反面例子

// 这是比较糟糕的方式
document.location.search
  .replace(/(^\?)/, '')
  .split('&')
  .reduce((searchParams, keyValuePair) => {
    keyValuePair = keyValuePair.split('=')
    searchParams[keyValuePair[0]] = keyValuePair[1]
    return searchParams
  }, {})

不要处理错误

无论在什么时候，发现报错了都不要处理它，也不要告诉任何人这里有错误，这样会显得你水平很低，写的代码总是报错

正面例子

// 这是比较好的方式
try {
  // 意料之外的情况。
} catch (error) {
  // tss... 🤫
}

反面例子

// 这是一种糟糕的方式
try {
  // 意料之外的情况。
} catch (error) {
  setErrorMessage(error.message)
  // and/or
  logError(error)
}

大量使用全局变量

使用全局变量，想在哪儿用就在哪儿用，这样很方便

正面例子

// 这是一种好的方式
let x = 5

function square() {
  x = x ** 2
}

square() // 现在x是25

反面例子

// 这是一种比较糟糕的方式
let x = 5

function square(num) {
  return num ** 2
}

x = square(x) // 现在x是25

创建你不会使用的变量

为了方便以后使用，预留一些变量，以防万一

正面例子

// 这是一种好的方式
let x = 5

function square() {
  x = x ** 2
}

square() // 现在x是25

反面例子

// 这是一种比较糟糕的方式
let x = 5

function square(num) {
  return num ** 2
}

x = square(x) // 现在x是25

类型可选，就别写

以 TS 为例，可以不用规定类型，那就别写类型

正面例子

// 这是一种好的方式
function sum(a, b) {
  return a + b
}

// 在这里享受没有注释的快乐
const guessWhat = sum([], {}) // -> "[object Object]"
const guessWhatAgain = sum({}, []) // -> 0

反面例子

// 这是一种糟糕的方式
function sum(a: number, b: number): ?number {
  // 当我们在JS中不做置换和/或流类型检查时，覆盖这种情况。
  if (typeof a !== 'number' && typeof b !== 'number') {
    return undefined
  }
  return a + b
}

// 这个应该在转换/编译期间失败。
const guessWhat = sum([], {}) // -> undefined

写永远无法到达的代码

正面例子

// 这是比较好的方式
function square(num) {
  if (typeof num === 'undefined') {
    return undefined
  } else {
    return num ** 2
  }
  return null // 这就是我的"Plan B".
}

反面例子

// 这是一种比较糟糕的方式
function square(num) {
  if (typeof num === 'undefined') {
    return undefined
  }
  return num ** 2
}

三角法则

正面例子

// 这是一种好的方式
function someFunction() {
  if (condition1) {
    if (condition2) {
      asyncFunction(params, (result) => {
        if (result) {
          for (;;) {
            if (condition3) {
            }
          }
        }
      })
    }
  }
}

反面例子

// 这是一种糟糕的方式
async function someFunction() {
  if (!condition1 || !condition2) {
    return
  }

  const result = await asyncFunction(params)
  if (!result) {
    return
  }

  for (;;) {
    if (condition3) {
    }
  }
}

混合缩进

避免缩进，因为它们会使复杂的代码在编辑器中占用更多的空间

正面例子

// 这种方式就很好
const fruits = ['apple',
  'orange', 'grape', 'pineapple'];
  const toppings = ['syrup', 'cream',
                    'jam',
                    'chocolate'];
const desserts = [];
fruits.forEach(fruit => {
toppings.forEach(topping => {
    desserts.push([
fruit,topping]);
    });})

反面例子

// 这种方式很糟糕
const fruits = ['apple', 'orange', 'grape', 'pineapple']
const toppings = ['syrup', 'cream', 'jam', 'chocolate']
const desserts = []

fruits.forEach((fruit) => {
  toppings.forEach((topping) => {
    desserts.push([fruit, topping])
  })
})

不要锁版本

永远使用最新的版本，这看起来很高级

函数长的比短的好

一个函数写一千行代码，不要去拆分

不要写测试

写测试是测试工程师做的事情，千万不要写测试

避免风格统一

在团队里面要有个性，尽量使用和团队其他人不统一的代码风格

不要删除无用的代码

把无用的代码注释掉，但是千万别删掉，万一后面要用到呢

不要写 README 文档

构建新项目的时候，不要写 README 文档，让用户自己猜

使用原则

竭尽全力写好的代码

我竭尽全力，使用毕生所学，依然写出来一堆屎山代码，从主观上来说，我是想把代码写得更优雅，
但因为能力有限，客观上写出来了一堆屎山代码，你只能在道德上谴责我，并不能在法律上约束我

不要嘲笑别人写屎山

因为你嘲笑的可能是自己，当你接手一个项目以后，大概率会吐槽前面的人写代码垃圾，维护别人的代码，
总是没有自己写的代码来得亲切，所以，当你在嘲笑别人写屎山的时候，可能别人也在嘲笑你，都是同行，
相煎何太急

不要恶意写屎山

有人说，我们推行的屎山代码风格指南里面，不写注释这条太弱鸡了，而他们的做法是：

在注释里面说谎

在法律上，故意犯罪和过失犯罪量刑的标准是不一样的，为此，我还特意去搜了一些文章，点击进入查看open in new window,大家可以去看看

如果你在注释里面说谎，量成重大事故，造成重大损失，那么，这个锅你是要背的，举个很简单的例子：

场景1: 对公司不满，采取报复行为，故意删数据库跑路

场景2: 因为技术菜，写出的代码有非常大的漏洞，造成了极大的损失

从上面两个场景，你应该明白主观上的故意和客观上的过失，就算量刑也是有轻重之分的，你一定要遵守我们这条原则

不要恶意写屎山代码，你自然发挥就好了

一份好的屎山代码并不具备破坏性

在《屎山代码风格指南》里面，你会发现众多的规则都有一个共同点，那就是不具备破坏性 也就是说你写出来的屎山代码，除了浪费后面接手的人更多的时间，浪费掉老板更多的人力成本，其他都还好，代码能正常的跑起来，举个例子：变量命名成 a 和变量命名成 age，本质上没区别，最后都是二进制在跑，唯一的区别就是维护代码的人恼火一点，话又说回来了，如果不是你维护代码，和你的关系不大

贡献者: mankueng