注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

埖堓

 
 
 

日志

 
 
关于我

雨落风尽花红, 太匆匆, 路几重, 一夜春来秋去晚来风。 月色朦, 云雾胧, 清华过尽逍遥醉苍穹。 人生路, 视不同, 自是如水若空怎能懂? 江湖泪, 是与非, 爱恨情仇流去几个冬。

网易考拉推荐

沈阳华威天下科技有限公司总结程序猿偷偷深爱的诸多不良编程习惯  

2017-03-03 10:23:29|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

其实我们曾经都做过这样的事情:当妈妈不注意的时候偷偷地吃糖果零食啥的,然后这些习惯就会导致有了蛀牙。同样我们年轻过所以都违背过一些编程的基本规则,违背了之后都会坚定地表示这种行为是不可取的。我们就是喜欢偷偷爱着这些不良的编程习惯。

 

我们对所谓的编程规则那是嗤之以鼻事实上输出的代码确实也很糟糕——可是我们依然活着。编程上帝没有下闪电劈死我们我们的电脑也没有爆炸。事实上只要我们能编译和发布代码客户似乎就很满意了。

 

这是因为糟糕的编程不像安装电路或者摸老虎屁股那样有直接的危害。其实在大多数时间里它也是可以工作的。规则通常是作为一种指导或格式上的建议并没有硬性规定一定要遵守,而这些也不会导致代码马上死掉。当然你的代码可能会被人耻笑甚至可能大家公开嘲笑你,但是这种挑战惯例的行为可以让人增加一点颠覆传统的快感,哪怕是在不经意间。

 

为了让问题变得更加复杂有时候违反规则反而更好。(一般人我不告诉他!)出来的代码会更干净甚至可能会更快和更简单。规则通常显得太过于宽泛有技巧的程序猿可以通过打破这些规则来提高代码。不要告诉你的老板这对你的编码生涯会很有意义。

 

下面这个编码习惯,虽然在编程规则中是被驳斥的但我们很多人就是会不由自主地使用它们。

 

编程习惯No. 1:使用goto

 

关于禁止使用goto可以追溯到许多结构化编程工具还未面世的时代。如果程序猿想要创建一个循环或跳到另一段程序中,那么他们需要输入goto后再跟一个行号。过了几年之后编译器团队让程序猿使用字符串标签取代行号。这在当时被认为是一个热门的新功能。

 

有的人认为这会导致“意大利面条式代码”。代码会变得不可读并且很难理解代码的执行路径。线程混乱缠缠绵绵到天涯。Edsger Dijkstra就三令五申地表示应该禁止这个命令他有一份诙谐的手稿题目为《Goto语句害人不浅》。

但绝对的分支是没有问题的。这就让人纠结了通常巧妙的 break 语句和return 语句可提供一个非常干净的关于代码在那个时候执行什么的声明。有时候添加 goto 到case语句会比更恰当的多级嵌套的if-then-else语句块更易于理解。

 

也有反例在苹果的SSL堆栈中的“goto fail”安全漏洞就是最好的例子之一。但是假若我们能够仔细避免case语句和循环的一些尴尬问题,那么我们就可以嵌入良好的绝对转移使阅读代码的人更容易明白这是怎么回事。我们可以插入break和return 语句让每一个人感觉更清洁和更愉快——可能得除了goto的敌视者。

 

编程习惯No. 2:成功避开文档

 

我的一个朋友他的老板非常精明,这位老板虽然从来没有写过任何代码但却秉持着每一个功能都必须包含在文档中的理念。哪个程序猿不提供注释那么他就会 受到惩罚。所以我的朋友在他的编辑器中联入了一个有点像人工智能的玩意儿,于是乎他的每一个功能就都有几行“文档”了。因为这位精明的老板还不够聪明 所以压根就没理解这些注释啥意思,也就是这样我的朋友逃过一劫。他的代码常常被作为正式文档。我想他应该快要升职了!

 

许多函数方法甚至一些类或多或少都能自文档化。冠以insertReservation或cancelReservation或 deleteAll 等名称的函数并不需要多此一举来解释它们的作用。其实为函数取一个正确的名字往往就足够了。事实上这比写一段长长的注释要好,因为函数名可以出现在代码中的其他地方。而文档只能默默地呆在某个角落。自文档化的函数名可以改进它们出现的每个文件。

 

在有些情况下写文档甚至会导致情况变糟。例如当代码瞬息万变团队像疯了似的重构的时候文档会产生分歧。代码是这样写的但文档解释的还是四五个版本以前的情况。这类“过时”的文档通常位于代码顶部有的人会在这里对代码应该发生什么作一个美好总结。因此尽管重构团队已经仔细修改了相关的注释,但还是会遗漏文件顶部的这段“美好总结”。

 

当代码和文本出现分歧的时候注释就变得毫无价值甚至会产生误导。在这样的情况下良好的自文档化的代码显然胜出了。

 

编程习惯No. 3:一行写太多代码

 

BOSS突然发神经地给团队发了一封讨厌的邮件:为了执行非常严格的风格规定所有人都必须重写我们的代码。最神奇的要求是每个行为或步骤或子句必须各自成行。你不可以使用点语法连续调用函数。在一个分支语句中你不能有两个及以上返回布尔值的子句。如果要定义变量那么另起一行。如果你正在做一个复杂的计算那么不要使用括号。每个片段也自成一行。

 

他认为他的这个法令将能使调试变得更加容易。就像你单步调试代码一样调试器会一个动作一个动作地前进。这样就不会卡在某一行而且更容易执行。

 

但是这样一来键盘上的回车键烦不胜烦,因为我需要不断地插入行。而且我敢肯定BOSS因此还可以到处吹嘘他的团队能写多少行代码。

 

有时在同一行中声明一堆变量反而更容易;有时把所有的布尔子句放在一起反而更简单——一切都能变得更加紧凑。那也意味着我们可以在屏幕上看到更多的逻辑而无需滚动鼠标。更易于阅读就意味着理解起来更快这才是简单的精粹。

 

编程习惯No. 4:不声明类型

 

那些热爱类型化语言的人认为如果为每个变量添加明确的数据类型声明,就可以写出更好的没有错误的代码。花一点时间来拼写类型能帮助编译器在代码开始运行之前标志愚蠢的错误。可能会让人觉得痛苦但很有帮助。这是编程中停止bug的一种有备无患的方法。

 

但是恰恰是时代变了。许多较新的编译器完全可以智能地通过查看代码来推断类型。它们会向后和向前浏览代码直到可以肯定这个变量是string 还是int抑或其他。如果这些被查看的类型不成队列那么错误标志就会点亮。因此再也不需要我们输入变量的类型了。

 

这意味着我们现在可以在代码中省略掉一些最简单的声明。代码更清洁而且阅读代码的人也猜得出for循环中命名为 i 的变量表示一个整数型。

 

编程习惯No. 5:摇摆不定的代码

 

有的程序猿在代码上特别优柔寡断犹豫不决。先是一开始将值存储为字符串然后又解析成整数。接着又转换回字符串。这是非常低效的你甚至可以感觉到CPU 在咆哮这种浪费负载的行为。聪明的程序猿之所以能快速地编码是因为他们事先会设计架构以尽量减少转换。他们的代码能快速地运行是因为他们有一个良好的 规划。

 

不过不管你信不信这种摇摆不定的代码有时候也是有意义的。比如说你有一个非常棒的库在它专有的黑盒子里能做无数智能的事情。如果库需要字符串的数据那么你就给它字符串,即使你刚将这个数据转换成为整数型。

 

当然你可以重写所有的代码以尽量减少转换,但是这需要时间。而且有时候让代码稍微多花点额外时间来运行也未尝不可,因为重写代码需要耗费我们更多的时间。有时背负这样的技术债务比一开始就正确构建的成本要更低。

  评论这张
 
阅读(50)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018