标签:知意 拼音 见名 代码 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
这样的工具。
而且越往后英语的重要性就愈加明显,比如你可以直接读一手英文资料、文献等。
标签:知意,拼音,见名,代码,Coding,技术活,英文,命名 来源: https://www.cnblogs.com/yuboon/p/11955869.html
本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享; 2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关; 3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关; 4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除; 5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。