究竟怎样写代码才算是好代码

今天让我们来谈谈代码吧。代码重要吗?当然,代码就是设计(Jack W.Reeves, 1992);代码是最有价值的交付物。我们需要好代码吗?在给“好代码”下个定义之前,这个问题无法回答。那么,究竟什么是好代码?

看下面这段英文解释:

‘Good code’ is code that works, is bug free, and is readable and maintainable. Some organizations have coding ‘standards’ that all developers are supposed to adhere to, but everyone has different ideas about what’s best, or what is too many or too few rules. There are also various theories and metrics, such as McCabe Complexity metrics. It should be kept in mind that excessive use of standards and rules can stifle productivity and creativity. ‘Peer reviews’, ‘buddy checks’ code analysis tools, etc. can be used to check for problems and enforce standards.

解释如下:

好的代码是代码运行正常、bug很少、并且具有可读性和可维护性。一些企业自己有所有开发人员都必需遵守的编码规范,但是对于什么样的代码是最好的每个人的都有自己的标准、或者有太多的或太少的编码规则。这有多种原则和标准,例如,McCable 的复杂度度量。的确使用过多的编码标准和规则可能降低生产率和创造性。“同行评审”或“同事检查”代码分析工具等,都能用来检查问题或坚持标准。

那么接下来我们深入介绍下,什么是好代码的标准呢,请看下面解释:

一、代码命名规范:

1、 package包名全部由小写的ASCII字母组成,用“.”分隔。在此项目中,所有的包均以“com.abc.ticket”开头。

2、 class 类名应当是名词,每个内部单词的头一个字母大写。应当使你的类名简单和具有说明性。用完整的英语单词或约定俗成的简写命名类名。

【示例】public class UserManager

3、 interface接口名应当是名词,每个内部单词的头一个字母大写。应当使你的接口名简单和具有说明性。用完整的英语单词或约定俗成的简写命名接口名。

【示例】interface TicketManagement

4、 Class 成员属性及变量的命名 (*) 变量名全部由字母组成,头一个字母小写,以后每个内部单词的头一个字母大写。变量名应该短而有意义。变量名的选择应该易于记忆。一个字符的变量名应避免,除非用于临时变量。通常临时变量名的命名规则为:i,j,k,m,n用于整数;c,d,e用于字符。

5、常量的命名,Java 里的常量,是用static final 修饰的,应该用全大写加下划线命名,并且尽量指出完整含义。

【示例】static final String SMTH_BBS=”bbs.tsinghua.edu.cn”;

6、数组的命名,数组应该总是用下面的形式来命名:byte[] buffer;

7、方法的参数和变量的命名规范一致,且应使用有意义的参数命名,如果可能的话,使用和要赋值的字段一样的名字。

【示例】setCounter(int size){ this.size = size; }

8、 方法命名(*)方法的命名应当使用动词,头一个字母小写,以后每个内部单词的头一个字母大写。在方法名的选择上应意义明确便于记忆。对于属性的存取方法,应使用getXXX()和setXXX()名称,以isXXX(),hasXXX()来命名返回值为boolean 类型的方法。

以上几条如果符合就算是好代码了吗?当然不是,这只是代码中最基本的命名规范而已,就算不符合最多就是代码不好看,没什么其他影响。

二、代码逻辑规范

1、需求、设计中的重点功能(结合需求/设计的评审产出)

2、代码格式校验

action/fa?ade等系统入口是否有数据格式校验

需要存入数据库的数据字段是否有长度校验

3、分支/循环

if-else/switch是否处理了所有分支

分支的条件语句是否有“副作用”;即,条件语句是否会改变系统状态/数据等

循环边界是否覆盖了所有元素

是否有死循环等

4、异常处理

是否有“吃掉异常”的情况

是否记录了异常日志

如果二次抛出,是否有合理的异常层次/结构

如果内部处理,对异常的处理是否能保证后续代码正常运行

5、单元测试

是否有单元测试

单元测试是否自动化

单元测试是否能完整覆盖需求

6、 事务处理

事务范围是否合理;或者说,是否把不必要的操作放到了同一个事务中

事务传播方式是否合理(required,never,new等配置)

7、sql语句

sql语句是否正确

使用mybatis的动态语句时,是否有潜在的sql语法问题

8、第三方组件

使用Redis,RabbitMQ等组件,是否真的对组件完全了解,在使用的过程中是否正确执行了开启与关闭操作。

写到这里,可能会有不少读者认为,代码规范也就这些了吧,按照上面二类写完算是优秀的代码了吗?其实还是远远不够。

三、可读性,可维护性

曾经看过一段代码,一个method几千行代码,所有业务逻辑都揉在了一起。然后没有人愿意再维护了,修改一点就会引发不可预知的错误,代码又臭又长。在这种情况只能重构,于是我在部门内部推广二本书《代码整洁之道》和《重构-改善既有代码的设计》并且制订部门自己的开发风格,通过组织所有开发人员练习小项目的开发,使整个部门的开发风格整齐划一,不管是老同事还是新同事,都能够非常快速的上手,程序中依赖度降低,结构非常清晰。

四、性能瓶颈

在真实工作中,很多程序员其实在开发完程序后不去真正关注程序的性能和响应时间到底如何,凭的是以往开发经验在开发的过程中尽可能的去减少问题点。

这样就只能在生产环境中去验证性能问题了,实际这种做法风险较大,所带来的损失也是较大的,我们在开发完程序后,不仅要采用Junit或者JMock这样的工具进行业务功能自测,更重要是能够采用相应的工具和命令进行代码性能和响应时间的测试,在第一关就能够找出可能出现的一部分问题点,那么经常使用的工具和命令如下:

top,vmstat,pidstat,Hprof,Btrace,Dtrace等命令。

具体可以参考我以前写过的文章二篇:

http://blog.csdn.net/u013970991/article/details/52035153

http://blog.csdn.net/u013970991/article/details/52035133

五、代码容错

  • 曾经有一个案例:

    X同事在“统一配置管理系统“中将一个参数配置在里面,当参数进行修改的时候相应的程序会马上做出改变进行相应逻辑调整,可是另一个A同事在操作这个系统的时候配错了参数,这时候系统在生产环境中就开始报错,以致于应用程序崩溃,逻辑无法进行下去造成较严重的生产事故,最后恢复完参数故障时间已经进行了十几分钟。针对这个问题当时产生了争论,到底是配置人员的错,还是开发人员的错。

其实在我看来,到底是谁的问题暂且放在一边,关键是开发人员是否在写程序的过程中有没有多一丝的思考,多考虑一些问题点,程序员要时刻怀着一颗怀疑的心和敬畏的心对待自己写的程序,像上面的问题我们完全可以做一些异常捕获和默认设置,在出错的时候至少能够让应用程序跑下去而不能整体报错,让用户无法继续使用。

  • 再说一个案例:

    某部门在开发“统一配置管理系统”,使用的是Zookeeper组件,而且它的工作原理是当某节点改变的时候,主动去通知所注册的系统,但是有个前提是如果那些系统,有一部分没有得到通知,有一部分得到了通知该怎么办,比如某几个系统在通知的时候正好在重启,这时候zookeeper就不能通知到相应的系统,于是在使用该“统一配置管理系统”的时候,出了生产事故。

其实还应该再重复说一下,程序员应该持有怀疑的精神面对调用的系统和被调用的系统,不要把稳定、安全、可靠寄托于别人身上。

究竟怎样写代码才能算好代码?这是一个有争议的话题,每个人的理解可能都不同,关键是通过讨论这个话题制订一个符合自己部门要求的规范,这样有依据的代码才可能成为好的代码。

时间: 2024-10-20 08:02:41

究竟怎样写代码才算是好代码的相关文章

“整洁可用”的代码才算是好代码

之前有人问我,什么样的代码才算是好代码?一时语塞,百度后,我觉得这个是我觉得我想要的结果,来源https://wenku.baidu.com/view/8646287bf56527d3240c844769eae009581ba2e8.html 原文地址:https://www.cnblogs.com/suola/p/9546682.html

什么样的代码才是好代码

衡量代码的好坏的指标或者维度有很多,比如性能好.架构好.高内聚等,这些指标的侧重点各不相同,不同的开发人员的关注的重点也各不相同.我个人更喜欢简单的可读性高的代码,我主要从以下几个维度衡量代码是否良好: 代码是可工作的 代码是可读性高的 代码是简单的 代码是高内聚的 代码是低耦合的 代码是可工作的 写代码的目的是要为了解决特定问题的,因此无论如何,代码首先是可工作的,能解决特定的问题.可工作的包含有两层含义:一是从功能角度来说能满足用户的需求,二是从性能角度来说要满足当前基本的性能需求.所以可工

如何写出规范的JavaScript代码

作为一名开发人员(WEB前端JavaScript开发),不规范的开发不仅使日后代码维护变的困难,同时也不利于团队的合作,通常还会带来代码安全以及执行效率上的问题.本人在开发工作中就曾与不按规范来开发的同事合作过,与他合作就不能用"愉快"来形容了.现在本人撰写此文的目的除了与大家分享一点点经验外,更多的是希望对未来的合作伙伴能够起到一定的借鉴作用.当然,如果我说的有不科学的地方还希望各路前辈多多指教.下面分条目列出各种规范要求,这些要求都是针对同事编码毛病提出来的,好些行业约定的其它规范

【整洁之道】如何写出更整洁的代码(上)

如何写出更整洁的代码 代码整洁之道不是银弹,不会立竿见影的带来收益. 没有任何犀利的武功招式,只有一些我个人异常推崇的代码整洁之道的内功心法.它不会直接有效的提高你写代码的能力与速度,但是对于程序员的整个职业生涯必然会带来意想不到的好处. 如果你还是一个在校学生,或者是刚工作没多久的"菜鸟",那么很有必要接触一些这方面的知识的.很显然,它会帮助你更快的适应企业级开发的要求. 1. 为什么需要代码更整洁? 在考虑代码整洁的时候,我们需要明确的一个前提是,这里不讨论代码的对错. 关于什么是

写可測试的代码

写可測试的代码 不论什么一个软件都是能够測试.在某种意义上,用户的使用过程也就是一个软件測试的过程.但是这并非我们今天要讲的可測试性.我们讲的可測试性指的是代码的可測试性,通俗点儿说就是是一串代码里包括的逻辑是不是能够被单元測试所覆盖.在这篇文章里我会从单元測试的基本概念開始引伸到怎样写单元測试,怎样写可单元測试的代码.文章里全部的样例都是C#写的,一来它是我职业生涯的主力语言.二来C#广为人知,相信对广大职业的或是业余的程序猿来说读懂C#的代码不会是什么特别困难的事情.实际上我描写叙述的方法和

巧妙的运用宏和函数写好你的C代码

究竟是用函数好,还是宏定义好? 比较两个数或者表达式大小,首先把它写成宏定义: eg: #include<stdio.h> #include<stdlib.h> #define MAX(x,y) ((x) > (y)? (a) : (b)) int main() { int a = 2, b = 4; int m = 0; m = MAX(2, 4); printf("%d\n", m); system("pause"); return

幸福村站——成都传智播客程序员写出你的烧烤代码

又是一个阳光明媚,风和日丽之天,如果作为程序员的你还在键盘上苦苦的想着下一串代码该怎么写的话,那你就弱爆了.俗语说得好,学习要劳逸结合,写代码更是需要清晰的思维,在传智播客Java基础班开班一个月后,班主任决定带着这群"猿猴们"去传说中的"幸福村"放松放松,我们也跟着一起去感受程序员们的烧烤代码的幸福吧! 带着好奇的心理走进了"幸福梅林站",一个又一个的农家乐园开始浮现在我们眼前,那里朴素的民风和美丽的风景让我们暂时忘却了学习上的烦恼和城市里的喧

利用|,&amp;,^,~,&lt;&lt;,&gt;&gt;&gt;写出高效艺术的代码

简介: 大家在阅读源码的时候经常会看到一些比如下面这样特别难理解的代码. cancelEvent.setAction(MotionEvent.ACTION_CANCEL | (motionEvent.getActionIndex() << MotionEvent.ACTION_POINTER_INDEX_SHIFT)); order = ((order) >> (INDEX_OFFSET -1) + 1) << INDEX_OFFSET; 类似与这种"高大上&

掌握解决问题的艺术,学会迭代开发,成为协作开发的专家,然后为写出更好的代码而担忧(转)

很多开发人员普遍犯有一个错误,认为他们的工作就是写代码.这不是一个开发人员要做的事情. 一个开发人员的工作是解决问题. 解决问题的一部分过程通常涉及到写代码,但是这部分工作是非常非常小的.开发有用的东西才花更多时间. 明白如何迭代开发,随着对问题有更好的理解,你才能给难题增加一些小功能,因为从头开发完美的产品是不可能的.不用写代码就能验证功能,因为很明显,写代码是相当昂贵的. 用于测试.评测和抛弃想法的系统也是极其重要的,因为要是没有它,整个开发组将耗费越来越多的精力,还有用来帮助他们执行得更有