1. 注释之争

    最近在开发这么一个编辑器,让运营自己编辑类目商品活动营销页。 这是个基于oo编程的项目,框架也是公司内部的框架,并没有使用目前mvvm类型的框架。 同时这个项目并非从0到1的过程,而是已经有70%的老代码,我们几个人是修改老代码符合新的需求,另一方面是在此基础上开发新功能。可以看到右侧已有很多封装好的功能组件,可以直接实例化。 自己开发新功能其实问题不大,问题在于去改别人的代码,并且是在旧代码的基础上已经modify之后的代码。 洋洋洒洒的600多行代码,一个注释也没有,同事的解释是,良好的命名就可以代替注释,另外一点就是,你写的注释,下一个人修改之后,可能不会顺带修改注释,那么注释的意义也就失效了。 乍一想,觉得挺有道理。然,当我看到下面这一段代码的时候,已经懒得去分析了,抛开代码写的好与坏。如果你的英语水平有过6级的话,我相信这命名还是能读的,但现实是绝大多数人的命名都无法翻译成可用的中文。更何况英文翻译成中文还是有歧义的,怎么确保读的那个人知道你的心思呢。 当然这也和读的人有很大关系。 相比之下,我更会在主体结构上写注释,至少让人知道,摸得着你的代码主体结构。争取5分钟就能入门,特别是在一些逻辑处理的深的地方更需要加注释,很多人都是临时创建一个变量,再去逻辑判断。一个不知道项目细节的人就要揣摩你的心思,浪费双方的时间,让你来给他讲解。 “哟,又在写bug了啊”这话常常被用来调侃或被调侃。殊不知,我们确实再埋bug,在埋坑给后人。 虽然不能约束别人写注释,但我自己还是会写,缪缪数语,即是给自己一个良好思路,也期望让别人能看懂我的代码。