什么样的代码才算是好代码

简介: 小编是一名7年iOS开发人员,在这里诚挚邀请各位还在坚持iOS的人程序员,不管你是十年大牛还是三年渣硕,肯学肯交流就加入我私人的一个交流群681503716,验证编码:大鲨,里面都有关于iOS的学习资料一起努力进步,我们为iOS付出那么多,不应该随便放弃吧什么样的代码才是好代码?衡量代码的好坏的指标或者维度有很多,比如性能好、架构好、高内聚等,这些指标的侧重点各不相同,不同的开发人员的关注的重点也各不相同。

小编是一名7年iOS开发人员,在这里诚挚邀请各位还在坚持iOS的人程序员,不管你是十年大牛还是三年渣硕,肯学肯交流就加入我私人的一个交流群681503716,验证编码:大鲨,里面都有关于iOS的学习资料一起努力进步,我们为iOS付出那么多,不应该随便放弃吧

什么样的代码才是好代码?衡量代码的好坏的指标或者维度有很多,比如性能好、架构好、高内聚等,这些指标的侧重点各不相同,不同的开发人员的关注的重点也各不相同。我个人更喜欢简单的可读性高的代码,我主要从以下几个维度衡量代码是否良好:

一、代码是可工作的

写代码的目的是要为了解决特定问题的,因此无论如何,代码首先是可工作的,能解决特定的问题。可工作的包含有两层含义:
1、从功能角度来说能满足用户的需求
2、从性能角度来说要满足当前基本的性能需求。

所以可工作是衡量代码好坏的前置条件,只考虑代码本身不考虑可工作性是舍本取末。

二、代码是可读性高的

代码是开发人员来开发和维护的,而且在软件漫长的生命周期中,通常会由不同的开发人员来维护的,如果代码的可读性很差将

来的维护就将是一个噩梦。我们写的代码是给开发人员看的,绝对不是给机器看的(编译后的代码是给机器看的,编译器会帮我们去掉无意义的空行等),因此代码必须首先是可读性高的。

那什么是可读性高的代码呢?从 coding style 角度来说,有意义的命名、添加必要的文档和注释、类和方法不要太长、每一行也不要太长、添加必要的空行以及必要的缩进等,具体可以参考《C++编程规范》和《重构改善既有代码的设计》。另外一方面就是从代码的结构来定义,例如代码是高内聚、低耦合的,代码是简单的,这三个方面下面会有详细描述。

三、代码是简单的


我们先来看一下什么是复杂的代码,比如说美其名曰为了代码的扩展性,使用了好多设计模式和软件开发原则,结果就是明明可以用很简单几行代码搞定的事情,结果用了几十行代码甚至更多,而且代码用了各种酷炫的技术,但是事实上大部分的扩展性可能一辈子也没有发生过,从敏捷开发角度来说,这是非常典型的过度设计。敏捷开发不是不考虑设计,只是不推崇过度设计,比如考虑 10 年后系统的扩展性是没有任何意义的,另外一种场景是只是做一个简单的后台管理系统,但是却花大量的精力考虑高并发也是没有意义的,过度设计的代码通常是复杂的。

所以在适度考虑代码的可扩展性的基础上,能不用设计模式就不要用设计模式,能不用新的、复杂的技术就不用新的、复杂的技术,技术够用就好,代码越简单越好,有人说代码太简单是不是有点 low,其实写出高质量的简单代码远比写出复杂的代码难度高,尤其是系统比较复杂时,保持代码的简单性难度是非常大的。

所以说简单的代码就是:代码所有人都看得懂,尤其是新人,但是又具备一定的扩展性和维护性,简单的讲就是简约而不简单。复杂的代码首先对读代码的人要求就很高,最终导致代码很难维护。代码是简单的是代码可读性高的一个方面。

四、代码是高内聚的


内聚是从功能角度来度量模块内的联系,代码关联性比较强的代码应该放在内聚在一起,形成一个独立的功能模块,可以是一个独立的类,也可以是一个微服务。其实判断代码是否内聚一个比较简单的方法就是看你能否给代码或者服务给一个贴切的名字,如果代码功能不内聚,我们是很难用一个简短的名字来表示它的含义的。

五、代码是低耦合的


耦合性(Coupling),也叫耦合度,是对模块间关联程度的度量。耦合的强弱取决与模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少。模块间的耦合度是指模块之间的依赖关系,包括控制关系、调用关系、数据传递关系。模块间联系越多,其耦合性越强,同时表明其独立性越差。
耦合比较高的代码危害比较大,最常见的表现就是改一个模块的代码会影响许多其它模块,最终必然导致大家不敢修改旧的代码,只能不停的添加新的接口,系统的可维护性非常差。

本文只是描述我心中的好代码,并不打算说明如何编写好代码,那需要太多的篇幅和太多的争议。所以,至此为止。

小编是一名7年iOS开发人员,在这里诚挚邀请各位还在坚持iOS的人程序员,不管你是十年大牛还是三年渣硕,肯学肯交流就加入我私人的一个交流群681503716,验证编码:大鲨,里面都有关于iOS的学习资料一起努力进步,我们为iOS付出那么多,不应该随便放弃吧

相关文章
|
8月前
|
程序员 测试技术
程序员的“Bug之旅”:为何无法一次性写出完美代码?
程序员在软件开发过程中难以一次性写出完美代码,需要不断修改和调试,即“改Bug”,这是由多个因素共同作用的结果。技术层面的复杂性、管理和流程上的不足以及个人能力和认知的局限性都是导致这一现象的重要原因。然而,这并不意味着无法避免或改进。通过加强需求管理、建立有效的版本控制和测试机制、推动团队知识共享以及鼓励代码审查和自我反思等措施,可以降低改Bug的频率和成本,提高软件开发的效率和质量。辩证地看待这一问题,既要理解其存在的合理性,也要积极寻求改进之道,以实现更好的产品和服务。
86 2
|
5月前
|
JavaScript 前端开发 程序员
JS小白请看!一招让你的面试成功率大大提高——规范代码
JS小白请看!一招让你的面试成功率大大提高——规范代码
|
8月前
|
设计模式 算法 Java
|
设计模式 人工智能 程序员
感觉自己的代码很乱?因为你不懂套路
编程教室开了这么久,已经有很多人从完全零基础的小白成为了会写代码的菜鸟程序员,能够自己独立开发程序。不过到此阶段,常常会遇到瓶颈,感觉功能可以实现
|
存储 JavaScript 前端开发
20个JS精简代码无形装逼集合,最为致命,记得收藏好
20个JS精简代码无形装逼集合,最为致命,记得收藏好
|
前端开发 小程序 IDE
「趣学前端」给不懂技术的朋友简单演示,代码是怎么被编写出来的
我身边不乏非程序员的朋友,对我的工作多多少少带点好奇心。突发奇想,准备了一个小功能,简单演示前端日常开发中的代码是怎么被编写出来的。
169 1
|
IDE 算法 开发工具
面向 CV 编程:COPY 了别人文章中的代码,想让代码能像作者一样跑通,应该注意什么呢?怎样才能让代码愉快地跑起来呢
一千个读者,一千个哈姆雷特,写代码也是如此,不同人,理解不同,逻辑不同,同一道题,代码各有千秋,所以出现的问题也是千奇百怪;预期结果就一个,解法却千千万。正如列夫托尔斯泰的安娜卡列尼娜中所说:幸福的家庭千遍一律,不幸的家庭各有各的不幸,但是主要不离题万里,错误基本能在一个常见的范围。 有人写代码是为了生计,有的人写代码仅仅是自己的兴趣使然。应该大多人都是第一种情况,我也一样,到了大学才拥有自己的第一台电脑,那时候智能手机刚出现,再往前倒推几年,手机都是个稀罕物,没有条件所以跟兴趣不沾边,唯一沾点边的是以前我喜欢刷竞赛题,锻炼逻辑,对学习算法有点帮助,但是作用有限。甚至有些人对自己所选的专业一无
1008 2
面向 CV 编程:COPY 了别人文章中的代码,想让代码能像作者一样跑通,应该注意什么呢?怎样才能让代码愉快地跑起来呢
|
前端开发 计算机视觉 Python
代码报错还好说,源码报错才难搞!分享自己源码报错的解决过程!
代码报错还好说,源码报错才难搞!分享自己源码报错的解决过程!
146 0
代码报错还好说,源码报错才难搞!分享自己源码报错的解决过程!
|
存储 Java
来自三段代码的疑惑~
来自三段代码的疑惑~
120 0
|
开发框架 缓存 监控
测试是否有必要看开发代码?如何能看懂?
测试是否有必要看开发代码?如何能看懂?