• Coding,命名是个技术活


    来吧

     

    日常编码少不了的事情就是给代码命名,代码中命名的重要性在项目前期不会有太大感受,因为是边做边命名,代码天天见,自然会加深记忆。但到了后期上线后半年一年后,再回过头看的时候,我擦,这个变量是啥意思?这个方法不对呀,不是更新用户状态的吗? 接下来就是各种吐槽,谁写的代码,这么烂,翻一下提交日志,哦?我写的,赶紧悄悄的改过来。

     

    经常性我们吐槽别人的代码烂,那么你是如何定义你认为的烂代码,它们烂在哪里 ?

     

    代码究竟烂在哪里

     

    这个问题说的具体点,可能经常我们在没理清业务逻辑的情况下去直接看别人的代码,相当于通过代码反推业务逻辑,别人的命名、编程思维跟自己的习惯不一致,需要时间去消化理解他的逻辑和习惯,然后加上代码排版乱七八糟,一堆 if else,还掺杂着各种奇怪的命名,魔鬼数字,OMG,简直不要太爽。以上综合起来,大概就是大家眼中认为的烂代码吧。

     

    简要总结下:

     

    • 自身原因,业务并未完全理解清楚,直接上手看代码

    这里是建议先搞懂业务逻辑和相关的实体或数据库表,最好是自己简要画出流程图或时序图辅助理解代码,展开说的话比较多,后面有机会单独一篇吧

     

    • 代码风格不规范

    体现在各种接口、方法、变量的命名不规范,代码格式排版混乱,过长方法,无注释或不详细等,注释这块最坑的不是没有注释,而是错误的注释。自己脑补下画面

     

    • 代码逻辑混乱

    体现在代码逻辑不清楚、冗余代码、废弃方法、深层的嵌套等,怎么优化,也值得单独写几篇

     

    可以看到命名在里面占有一席之地,那么如何做好代码中的命名,且往下看。

     

    好的命名,看这里

     

    先给出结论,一个好的命名最最最关键的一点,见名知意,见名知意,见名知意,重要的内容重复三遍,并加个底色。

     

    不要怕长

    我工作中碰到不少人有个命名习惯,我称为半命名方式,看个例子,定义一个业务需求的实体类,正常见名知意的命名是这样的BusinessRequirement,但是,他们觉得这样太长,他们会这样

    BusRequi、(各省一半)

    BusinessReq(后面省一半)

    BusinessXq(一半英文、一半拼音,洋不洋气

    这样的命名完全不具有可读性,还容易产生歧义。所以,不要怕长,能让人和有道词典读懂是前提。

     

    看个springboot中的命名

    SpringApplicationJsonEnvironmentPostProcessor

    长吗?但肯定能读懂对吧。

     

    但是有一类是可以简化的,就是行业内大家公认的术语简称,比如你想整个ip工具类,那么你可以这样命名IpUtil,就没必要整成这样InternetProtocolUtil,因为Ip这个词在业内大家都懂,就可以简写。

     

    准确

    准确就是命名要符合当下的业务场景,比如我老早之前做的考试类项目中有个题目实体,同事采用的命名是Problem,显然放这里是不合适的,最后纠正为Question。要做到准确,还是比较考验英文功底的。

     

    具体

    具体就是能正确表达变量或类所指向的代码含义,例如我们定义了一个代表软件版本号的数组,可能会这样定义

     

    int[] array = new int[] {1,2,3,4,5};

     

    数组倒是能看懂,但是单看这一行代码并不能搞清楚干什么用,放在具体的代码逻辑里结合上下文代码,倒也能推导出来数组中定义的具体是什么,但是增加的阅读代码的难度,好一点的当然是下面这样

     

    int[] versionNumberArray = new int[] {1,2,3,4,5};

     

    说清楚具体含义,表示的是什么数组,而不是抽象的表达个数组的概念。

     

    额外补充一点

    我见过一个项目从代码到数据库整体命名都是拼音简写形式,说实话拼音简写对业务不熟悉人来说很难识别,而且时间一长完全是懵逼的,完全得靠猜。

     

    拿上面的业务需求来说拼音整出来Ywxq,拼音组合可以有很多种解读。项目得以持续维护的关键是他们有详细的字典说明文档,实际上就是上篇文章说的公司或团队有一套自己的标准就行

     

    但是可想而知仍然很痛苦,除非是个别领域内的专业词汇,英文很难表达,可以尝试拼音解决,其他情况还是尽量用英文命名。

     

    总结

     

    好的命名就是做到见名知意,具体遵循以下几点:

     

    1、不要怕长,专业术语行业内有简称,可用简称

    2、用词准确
    3、表达具体

    4、尽量使用英文

    5、上面没提到的一点,公司有规范,优先符合公司规范

    未入行之前,很多人总是好奇,英文基础对编码到底有没有影响,到底有多大,这里就可以看到,是有影响的,起码命名的时候有障碍,需要借助有道词典或 code if 这样的工具。

     

    而且越往后英语的重要性就愈加明显,比如你可以直接读一手英文资料、文献等。

     

    最后

    写完了老感觉烂代码这个词用的很不好,奈何词穷,先这么着吧。

     

  • 相关阅读:
    Latex文件如何拆分进行独立编译?
    梯度下降优化算法
    Google大脑科学家贾杨清(Caffe缔造者)-微信讲座
    Jeecg 如何执行批量insert或者update操作,高效率
    【JEECG_3.7.1】列表多表头的设计
    t:formvalid中定义callback函数
    Excel导入的时候日期格式会变成double式的String数据处理
    sql 跨表修改的方式
    js判断字符串str是否包含字符串substr
    帆软报表和jeecg的进一步整合--ajax给后台传递map类型的参数
  • 原文地址:https://www.cnblogs.com/yuboon/p/11955616.html
Copyright © 2020-2023  润新知