代码可读性测评：逻辑清晰与规范至上

　　去年春晚那项目，改稿改到第九版的时候，我盯着代码里那坨嵌套了五层的if-else，突然就懂了什么叫“可读性”——不是给机器看的，是给人看的啊！前端小王在旁边刷短视频外放，我拍桌子喊“这逻辑能再乱点吗？”，他头都没抬：“哥，你行你上啊，规范文档里可没写这得怎么缩进。”

　　我原以为代码规范就是“用空格不用Tab”“变量名别用拼音”，结果那项目里，光是“按钮状态”的命名就改了八版——正常是.btn-normal，悬停是.btn-hover，禁用是.btn-disabled，可总有人写成.btn-nor、.btn-hov、.btn-dis，切图文件夹里更乱，什么“按钮_正常_02.png”“btn_悬停_最终版.jpg”，我翻着翻着就把数位笔的笔尖给掰断了——刚换的，还挺脆。

　　但最要命的还不是命名，是逻辑。那会儿需求是“用户点击按钮后，如果网络正常，显示加载动画；如果网络慢，显示提示文字；如果网络超时，显示错误图标”——听起来简单？可代码里写着：先判断网络状态，再判断按钮状态，再判断动画是否加载，最后还要判断用户有没有在三秒内点击过其他按钮……我数了数，光是嵌套的if就七层，前端小王还补刀：“哥，这逻辑多清晰啊，每一步都写了注释。”我指着屏幕：“注释是给人看的，你这代码是给人猜谜的吗？”

　　后来我翻出三年前测过的另一个项目——那代码写得那叫一个干净，变量名全是英文，缩进全用空格，每个函数不超过20行，注释就写“// 加载用户数据”，多一个字都没有。可你猜怎么着？那项目上线后，维护的人换了两拨，到现在都没出过bug。而去年春晚那项目，上线第一天就崩了三次，每次都是“网络状态判断逻辑冲突”——规范？逻辑？这时候才看出谁在裸泳。

　　窗台上的绿萝死了半盆，我盯着那枯叶子想，代码规范这玩意儿，就跟设计稿的栅格一样——你不用的时候觉得它束缚，可真出了问题，才知道它是在救命。比如那按钮的命名，如果一开始就定死“必须用英文+下划线”，切图的人就不会乱写；比如那网络判断的逻辑，如果一开始就规定“只能用三层嵌套”，写代码的人就会想办法拆函数、抽公共逻辑，而不是堆代码。

　　可现实是，大部分项目的规范文档，都是“拍脑袋”写的——产品说“要高级感”，设计说“要留白”，前端说“要兼容IE”，测试说“要可维护”，最后规范文档里全是“建议”“尽量”“最好”，没有一条是“必须”。我见过最离谱的规范，是“按钮颜色根据页面主色动态调整”，结果前端写了200行CSS变量，最后发现色板里那个说不清的灰（#f5f5f5和#f6f6f6），根本分不清哪个是主色，哪个是背景色——显示器还有点色偏，我盯着屏幕看了十分钟，眼睛都快瞎了。

文章配图，仅供参考

　　所以我现在测评代码可读性，就盯两点：逻辑是否清晰，规范是否严格。逻辑清晰的标准是“不用注释也能看懂”，规范严格的标准是“违反规范就报错”。比如那按钮命名，如果切图时系统自动检查命名格式，不符合的就直接拒绝上传；比如那网络判断逻辑，如果代码审查时发现嵌套超过三层，就直接打回重写——优胜劣汰，就是这么简单。

　　可现实里，能做到这两点的项目太少了。大部分团队都是“先赶进度，再补规范”，结果补着补着就乱了——就像我桌上那只干了的马克杯，刚买的时候天天洗，后来懒了，放一周都不碰，现在里面都长毛了。代码规范也一样，一开始不严格，后面再想严格，成本高得吓人。

　　我现在跟产品吵架，跟前端撕逼，跟测试扯皮，就为了一件事——把规范写死，把逻辑拆清。哪怕多花两天时间，也比上线后天天救火强。去年春晚那项目，后来我逼着前端重写了网络判断逻辑，拆成了三个函数，每个函数不超过50行，注释就写“// 判断网络是否正常”“// 显示加载动画”“// 处理超时错误”——简单吧？可你猜怎么着？上线后三个月，没出过一次bug。

　　所以啊，代码可读性这事儿，真不是“写得好看”那么简单。它是给后来者留的活路，是给团队省的时间，是给项目保的命。下次再有人跟你说“规范不重要，逻辑清楚就行”，你就让他看看去年春晚那项目的代码——保证他看完就想辞职。

　　当然，我也承认，这世界没有完美的规范——就像没有完美的设计稿一样。但至少，我们可以让规范严格一点，让逻辑清晰一点，让后来者少骂两句街。至于我？我现在写代码，都先想“如果是我徒弟接手，他能不能看懂？”——能，就写；不能，就改。毕竟，谁也不想自己的代码，最后变成“猜谜游戏”。

（编辑：天瑞地安资讯网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!