let sum = 1 + 1;某烂代码可能是:
let a = {}; let b = {}; a.toString = function() { return 1; }; b.valueOf = function() { return "1"; }; let sum = a + b;把简单的逻辑搞复杂,便是绝大多数程序员的拿手好戏(当然也包括我)。因为我从大学就开始带团队做项目了嘛,所以经常会审查团队同学的代码,做好二次校验。包括现在虽然开公司了,前端 / 后端同学的代码,也都会在我这过一遍才会发布上线。总之算是看了很多代码,其中有一些真的是让我哭笑不得。下面给大家分享一些代码片段出来,希望大家 不要学习 。
const [l, setL] = useState<boolean>(false); const [d, setD] = useState<any>();但如果我稍微完善下命名呢:
// 堆代码 duidaima.com const [loading, setLoading] = useState<boolean>(false); const [data, setData] = useState<any>();很多同学应该立刻能看懂了,一个是 “加载中” 的变量,一个是 “存储数据” 的变量。最好的代码应该是不用写注释的,因为 代码即注释 。如果你能把命名做到 “见名知义”,看代码的人会极度舒适。
if (condition1) { // 逻辑 A if (condition2) { // 逻辑 B if (condition3) { // 逻辑 C if (condition4) { // 逻辑 D } } } }这里的深度有 2 重含义,一重是字面意思:代码一层嵌一层、深不见底;另外一重是指真的 “很有深度” —— 指让人看不懂。阅读这段代码的感觉就像是你在一座巨大的迷宫里,每次转弯都要判断下是左还是右,最后你只会迷失方向。
if (!condition1) // 逻辑 A return; if (!condition2) // 逻辑 B return; if (!condition3) // 逻辑 C return; if (!condition4) // 逻辑 D return;这样,你的代码就清晰了很多,阅读这种代码的感觉就像是走在了一条直路上,前方的路一目了然。当然,还可以将一些逻辑抽象成独立函数来简化代码,或者使用设计模式来优化。怎么判断一段代码是否过于复杂、应该优化了呢?这里提到一个概念:圈复杂度 ,这是一种量化代码复杂程度的概念。通常你代码中的 if else 分支越多,圈复杂度就越高,代码就越复杂。
3.没有用到的代码,又不舍得删除
<Spin spinning={!(currDownloadUrl || originPictureUrl || pictureUrl)}> {type === DRAW_APP ? ( drawImg(image) ) : ( drawImg(currDownloadUrl || originPictureUrl || pictureUrl) )} </Spin>第一眼看到这段代码时,我就发现了,判断 spinning(旋转)的代码逻辑比较复杂,包含了两个 || 逻辑。而下面的 drawImg 函数的参数中,又包含了这段一模一样的逻辑。这段判断,其实就是冗余代码,完全没必要写两遍!
// 要展示的图片地址 const showPictureUrl = currDownloadUrl || originPictureUrl || pictureUrl;直接定义一个通用变量,写上清晰的注释,其他地方要使用时就无需关注内部判断逻辑,看注释就行了。这就是所谓的 DRY 原则(Don't Repeat Yourself) ,尽量避免代码冗余。如果你在多处写下相同的代码,那么当需要修改这段代码时,你就需要在所有这些地方都修改,漏一个地方就是一个 Bug。
这里打个比方,写代码就像是我在公司里堆东西,一开始总觉得多一点没关系,反正有空间。但是,冗余代码就像是杂物,会越堆越多,迟早有一天,会影响到你,就像我们公司现在一样(右边有一堆杂物):