代码规范作为每个开发小组必备的文档，我们总希望通过代码规范解决代码可维护性的问题。然而，理想很丰满，现实很骨感。
拿我们经常碰到的命名规范来看，命名规范主要有以下四点：
- 规定大小驼峰、下划线这些命名方法的使用
- 对_、$等特殊字符和数字使用的规范
- 变量、常量为名词，方法名为动词
- 可读性好，望文生义
很显然，除了第 1 点之外，其他都是很难在工具上完成的。工具（不含AI）拿 list1、list2 这种没办法，也没办法区分动词和名词、拼音和英文，更没办法望文生义，在专业软件中，这甚至还要一定的业务背景知识，而望文生义这点对代码可维护性贡献最大。
可见，要真正做到代码可维护性有多难。那我们有什么规范可以解决大部分的代码问题呢？也是有的，那就是：
文件最长行数、函数最长行数
这两条在大部份的规范中很少提及或被大部分人忽略的。然而却是我个人更推荐的规范。很显然这是一条机器扫描就能完成的规范，要执行下来，是非常容易的。
你跟开发说，要做模块化、一个函数只做一件事、不用重复自己......别人都懒得理你。但是只要把文件行数、函数行数规定下来，一切就自然而然发生了。
在过往的项目中，我规定了文件最长行数是600，函数最长行数是30。
json
/* eslint */
{
"rules": {
"max-lines": ["error", 600],
"max-lines-per-function": ["error", 20]
}
}以前端为例，当触及 600 行时，开发就会想着如何把部份代码移出去。对一个初学者而言，可能会首先把样式文件移出。也许大佬们会嘲笑这种行为，认为他们把不应该迁移的迁移出去了。但是没所谓，随着业务的复杂度增加，页面的复杂度也会增加，他们就会发现这种避重就轻的方法是无济于事的。
于是，他们就会想着把部份代码做成组件，父子组件的交互、全局状态值的管理等等会被了解并逐渐应用到实际开发中。于是模块化就这么慢慢完成了。
到最后组件的文件也超长了，开始想着代码复用，将重复率高的代码抽取成公共工具，通过参数的不同做不同的处理。于是一个函数只做一件事、不用重复自己这些规则，也慢慢地在他们的代码中发生了。
另外在物理意义上，代码选择 14 像素，行高 1.5，即 21 像素，30 行的代码行高 620 像素，这样即使在笔记本的 1366*768 屏幕上能看完一个函数。当把代码折叠起来，600 行也大概有 20-40 个的函数，也能 1-3 屏看完。这样也是方便查找的。
所以，推荐大家都把这一条简单易执行的规范加入你公司的规范吧。
从此屎山代码不再是屎山，最多也就是一小坨一小坨的屎，清理起来也容易多了。哈哈哈～