“相信很多程序员都有这样的困惑,如何才能写出好的代码?作为一个开发人员,我深有体会。即使你开始努力把它写好,可到了后来,你始终逃不过一堆垃圾代码的宿命。严格开发流程?重构?使用最好的开发设计工具?问题不是出自这里,问题出在人的身上。下面的这幅漫画很有意思,是我们日常开发中经常碰到的情形,急剧讽刺意味。”

 

新手程序员必读:探讨如何写出好代码? 

 

  从上图给出的意思,进入了死循环,永远也写不出好的代码了。以上是笔者在论坛上看到内容,贴上来与大家讨论。以上观点的作者是将代码好坏的标准放在是否适合项目的需求,笔者认为,如果单论代码的好坏,那与项目需求无关,需求变化那是项目主管的责任。程序员不管是在任何时候,是都可以写出好的代码来的。下面是笔者找到的一些写出好的代码的标准和方法,分享给大家!

  一流代码的特征

  1、稳定可靠(Robustness)

  代码写出来以后,一定要能够运行得非常好,非常稳定可靠。在现今的IT行业,软件产品都是是24*7,即要保证系统一天24小时,一星期7天中都可以无间断的正常运行。比如我们百度的搜索引擎系统,比如我们的通信系统,等等。到了产品开发后期,大部分的成本都将投入到产品稳定性的提高。

  2、可维护且简洁(Maintainable and Simple Code)

  在写代码时,首先要考虑的是:写出来的代码不但要自己可以读懂,而且我们的同事、测试工程师都可能要修改这些代码,对其进行增减。如果代码很复杂,不容易读懂,如程序中的递归一大堆、程序不知何时或从何地跳出,则会使程序的可维护性和简洁性降低。所以必要的注释、统一的编程规范等都是非常重要的。

  3、高效(Fast)

  在软件行业中效率是非常重要的,比如搜索引擎。有些软件的搜索效率就不高,搜索过程特别缓慢,让人难以接受。当然这里面有一个带宽的问题,但是程序效率不高也是一个重要的原因。而实际上程序的效率提高,有时候很简单,并没有什么神秘之处,如使用数组索引时候,可以用指针方式而不使用数组下标;数组的空间定义应该定义为2的N次幂等等。

  4、简短(Small)

  这方面大家的感受可能不是很深,但是我的感受是很深的。配置过PSTN程控交换机、路由器、VoIP网关设备的人都知道,这些设备的软件都是从PC机通过网口或串口下载到这些设备的Flash上(类似PC机的BIOS)再通过设备上的CPU启动。如果程序写的很罗嗦,随着特性不断增加,程序规模将变大的巨大,Flash空间告急、内存告急、下载升级变的不可忍受,等等,带来的就是成本不断增加,利润不断下降。

  5、共享性(Reusable)

  如果做大型产品开发,程序的共享性也是非常重要的。我们产品有那么多开发人员,如果每一个人都自己定义字符串、链表等数据结构,那么开发效率就会降低,我们的产品恐怕到今天也不能出台。我所说的“共享”不是指将别人的代码复制到自己的代码中,而是指直接调用别人的代码,拿来即可用。这一方面可以减少代码的冗余性,另一方面可以增强代码的可维护性。如果别人的代码里有Bug,只需修改他的代码,而调用此代码的程序不用进行任何修改就可以达到同步。这同时要求我们在设计的时候,如何考虑系统的内聚和耦合的问题。

  6、可测试性(Testable)

  我们的产品开发里,除了软件开发人员,还有一部分工程师负责软件测试。软件测试人员会将开发代码拿来,一行一行地运行,看程序运行是否有错。如果软件开发人员的代码不可测试,那测试工程师就没有办法进行工作。因此可测试性在大型软件开发里是很重要的一点。可测试性有时候与可维护性是遥相呼应的,一个具有好的可测试性和可维护性的代码,测试人员可以根据开发提供的维护手册、debug信息手册等就可以判断出程序出错在哪个模块。

  7、可移植性(Portable)

  可移植性是指程序写出来以后,不仅在windows 2000里可以运行,在NT/9X下可以运行,而且在Linux甚至Macintosh等系统下都可以运行。所有这些特性都是一流代码所具备的特性。但是其中有些特性是会有冲突的。比如高效性,程序写的效率很高,就可能变得很复杂,牺牲的就是简洁。好的代码要在这些特性中取得平衡。

  写好代码的10个秘密

阿里云-推广AD

  1、百家之长归我所有(Follow Basic Coding Style)

  其实写代码的方式有很多,每个人都有自己的风格,但是众多的风格中总有一些共性的、基本的写代码的风格,如为程序写注释、代码对齐,等等。是不是编程规范?对就是编程规范。

  2、取个好名字(Use Naming Conventions)

  取个好的函数名、变量名,最好按照一定的规则起名。还是编程规范。

  3、凌波微步,未必摔跤(Evil goto’s?Maybe Not…)

  这里我用“凌波微步”来形容goto语句。通常,goto语句使程序跳来跳去,不容易读,而且不能优化,但是在某种情况下,goto语句反而可以增强程序的可读性。Just go ahead,not go back。

  4、先发制人,后发制于人(Practic Defensive Coding)

  Defensive Coding指一些可能会出错的情况,如变量的初始化等,要考虑到出现错误情况下的处理策略。测试时要多运行几个线程。有些程序在一个线城下运行是正常的,但是在多个线程并行运行时就会出现问题;而有些程序在一个CPU下运行几个线程是正常的,但是在多个CPU下运行时就会出现问题,因为单CPU运行线程只是狭义的并行,多CPU一起运行程序,才是真正的并行运算。

  5、见招拆招,滴水不漏(Handle The Error Cases:They Will Occur!)

  这里的Error Case(错误情况),是指那些不易重视的错误。如果不对Error Case进行处理,程序在多数情况下不会出错,但是一旦出现异常,程序就会崩溃。

  6、熟习剑法刀术,所向无敌(Learn Win32 API Seriously)

  用“剑法刀术”来形容一些API是因为它们都是经过了很多优秀开发人员的不断开发、测试,其效率很高,而且简洁易懂,希望大家能掌握它,熟悉它,使用它。是不是象我们的ULIB。

  7、双手互搏,无坚不摧(Test,but don’t stop there)

  这里的测试不是指别人来测试你的代码,而是指自己去测试。因为你是写代码的原作者,对代码的了解最深,别人不可能比你更了解,所以你自己在测试时,可以很好地去测试哪些边界条件,以及一些意向不到的情况。

  8、活用断言(Use,don’t abuse,assertions)

  断言(assertion)是个很好的调试工具和方法,希望大家能多用断言,但是并不是所有的情况下都可以用到断言。有些情况使用断言反而不合适。

  9、草木皆兵,不可大意(Avoid Assumptions)

  是指在写代码时,要小心一些输入的情况,比如输入文件、TCP的sockets、函数的参数等等,不要认为使用我们的API的用户都知道什么是正确的、什么是错的,也就是说一定要考虑到对外接口的出错处理问题。

  10、最高境界、无招胜有招(Stop writing so much code)

  意思就是说尽量避免写太多的代码,写的越多,出错的机会也越多。最好能重用别人开放的接口函数或直接调用别人的api。