代码健壮性是真的好吗?

我在看一个视频,这个视频里写的代码有这个特点,那就是它把代码写的一个方法可以多次被调用或者说叫利用也可以;同时视频也在一致强调这一点;那我就疑惑了,代码健壮性就那么好吗?

首先,你要写的一个方法能实现不同的功能,在开始设计它的时候就要考虑到各个问题的方方面面,这个对精力应该也是一个很大的消耗吧;这些代码也许写的人能轻松的能读懂,但是如果是别人来读的话,那耗费的时间和精力应该是更大的;如果是更大型的软件,恐怕程序员都要白头了吧;这难道是炫耀技术吗?这个代价也太大了!

其次,现在电脑运算速度是很快的,写一点臃肿些的代码对于整个软件的应用应该不是什么问题吧;当然对于要求软件大小的应该是个问题;所以,我认为代码的健壮性应该需要和臃肿的代码共存的;如果一味的追求代码健壮性或臃肿的代码都不是什么好的事情;我认为代码量也是一种技术的炫耀的,因为读这样的代码也需要花费大量时间和精力的;

反正不管怎么说,对于我来说,我更喜欢写臃肿的代码,然后将它们稍微修改一下;

时间: 2024-09-29 09:07:45

代码健壮性是真的好吗?的相关文章

关于提高代码质量的思考之提高代码健壮性

接着上期的拓展性之后,今天谈谈代码的健壮性.代码的健壮性又称鲁棒性,是高质量代码的一个重要指标. 有人分析了印度软件行业比中国好的一个原因:印度的一个老程序员,月代码量在一千行左右,这一千行代码,算法平实,但都是经过仔细推敲,实战检验的代码,不会轻易崩溃的代码.我们的程序员,一天就可以写出一千行代码,写的代码简短精干,算法非常有技巧性,但往往是不安全的,不完善的.印度人的程序被称作:傻壮.但程序就得这样! 那么如何写出一个代码简短精干,算法非常有技巧性,而又非常安全的代码呢?我逛了很多论坛,发现

关于代码健壮性

今天有许多客户反映我们的APP的一打开就崩溃,因为是首页的是我做的,我马上打开APP看看,果然如此.我的同事debug了代码,原来的首页的banner图片返回是NULL,这是服务端那边返回的,我们无法控制的.但是我们客户端就没有责任吗?我们做客户端不能保证服务端一定有给我们返回数据,有些情况下可能为NULL.今天就正好就发生了这种情况.看了下我的代码,我的就加了一层判断首页返回的model类的对象不为空,但是没有判断banner的图片信息返回是否为空.如果为空,我也赋值给了viewpager,肯

linux下,简单一行代码提高脚本的健壮性

前言 新来的美女同事,拿她写的脚本向我请教时,我证实了程序猿经常说的一句话:OMG,这么狗屎的代码居然是我写的!!! 问题描述: 在linux/unix写脚本时,我大多习惯在第一行加上(或许还有一大班跟我一样习惯的人): #!/usr/bin/bash 或者 #!/usr/bin/perl 或者 #!/usr/bin/python…………………… 用于操作系统执行这个脚本的时候,调用/usr/bin下的bash/perl/python解释器. 但是,这时存在两个小小问题: 1.本机的bash/p

【转】真实案例引起的对系统健壮性的思考(张逸,2012-02-07)

大年初四(2012年1月26日)上午,我在重庆移动某营业厅的自助客户端使用招商银行信用卡为我妻子充话费(我妻子的手机已经停机).在插入信用卡并输入密码后,系统提示正在交易.大约几秒后,我的手机收到招行的短信,提示消费100元,但自助客户端仍然显示正在交易.此时的我已经有了不详的预感.果然,在等待大约一分钟,系统提示操作失败,之后系统崩溃,弹出了一个Windows命令窗口.因为我妻子的手机停机了,所以立刻可以确认上一次充值确实是失败的.而我的手机能收到信用卡的消费信息,则可以确认银行确实已经支付了

软件构造 7-1 健壮性与安全性

健壮性与安全性 什么是健壮性与安全性? 如何衡量健壮性与安全性? 健壮性:系统或组件在存在无效输入或压力环境时一颗正确运行的程度. 健壮性编程关注异常终止和异常活动的处理. 健壮性原则:严于律己(满足specification),宽以待人(接受各种输入) 健壮性编程原则(把用户当做小孩) 1.用户会修改代码,而且自己写的还不对 2.用户不会看specification(所以我们应该在他操作错误时返回明确的错误信息帮助其改正) 3.危险行为,我们不应当将信息暴露给用户,以至于产生漏洞,使用户专注于

软件构造-犯错的艺术——健壮性与正确性,异常,防御式编程,debugging与test的思考与总结

健壮性与正确性 健壮性与正确性是不同的——一个倾向于使程序尽可能保持运行,即使遇到错误,一个倾向于使程序尽可能正确,不在意保持运行 异常 异常分为两种——checked exception与unchecked exception 二者的区别在于: checked exception需要显式的处理,说白了就是编程者必须要么用catch抓住它,然后在try中想办法处理掉,要么显式的将这个异常扔到调用的上一级方法,也就是甩锅.总而言之,你永远不能无视checked exception unchecke

采用[ICONIX] 方法实践分析和设计之四 [健壮性分析]

在前三章中通过(问题域)建模和用例分析之后,在许多的UML书中可能接下来就要进行时序图和协同图的绘制了.但是问题好像还没那么简单,因为这里有一条鸿沟还没有跨过去,正如下图所示:                    在我刚学开始学习 UML时,在拿到用例文本时要去画时序图总感觉有些别扭,不知如何才能将文本中的意思完全用图的形式表达出来,总是感觉分析出来的文本中缺了一些很重要的东西, 而这些被丢掉的对象最终可能会导致无法绘制时序图,但又找不出用例文本中到底还有什么东西被遗漏,最终导致设计瘫痪.后来

性能测试 - 响应 vs 延迟 vs 吞吐量 vs 负载 vs 扩展性 vs 压力 vs 健壮性

本文译自Niraj Bhatt 所著 Performance Testing - Response vs. Latency vs. Throughput vs. Load vs. Scalability vs. Stress vs. Stress vs. Robustness. 原文地址:https://nirajrules.wordpress.com/2009/09/17/measuring-performance-response-vs-latency-vs-throughput-vs-lo

python Selenium2Library element操作的健壮性封装、普通操作不受影响

"""     对Selenium2Library element操作的健壮性封装.普通操作不受影响.     每个element操作方法生成一个操作对象    ''' 2类对象:         father类型: fatherName=None eleMethodName=webObj.browserName,            一般在webObj创建时配套创建, _eleMethod_objDc中记录,形如{fatherName:{}}        非father