程序员深爱的11个不良编程习惯

2017-05-03 admin 24

1、使用goto

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

2、成功避开文档

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

3、一行写太多代码

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

4、总出现错误的变量名和函数名拼写

让很多人想不通的是,为什么大家都知道这个习惯对自己没有好处,为什么还是有人让他出现,以至于常常出现错误的变量名和函数名的拼写。而且这些错误的拼写总是隐蔽的很好,也很难被发现。

想要解决这个问题,我们可以在一个比较成熟的开发环境上写代码,又或是用程序员专用的文本编辑器,这些都可以减少拼写错误。也可以用特定的变量名和函数名,这样容易拼写,也容易发现写错的地方。

5、不按规定的格式写代码

常用的缩进和格式化能让写出的代码一目了然,有什么错误一看就知道。而且别人看着也方便。

倘若你使用的是不会自动格式化的代码,那你可以考虑用代码美化软件,如Uncrustify,因为他允许用户自定义格式要求,接着它会按你的要求执行任务。

6、不按规定的模块化编写代码

长函数实现的路径太多,常常测试起来就很麻烦,所以要习惯于一个函数对应一个指令,这样及简短又容易理解和维护。

7、总是依赖IDE

不用多说,大家都知道,IDE能让你的代码写的又好又快。他们能提你想用的很多东西和选择提示。但也会存在一定的风险,若你不能确保自己有足够的细心,那么很容易会出错。

好的工具的确是个不错的帮手,他可以消除拼写错误,还可以提高我们的工作效率,如果你还不够细心,那同样用了这些也还是会出问题。

8、总是写死密码

一些人总是喜欢在程序里写写死帐户名和密码,这样可以方便进入系统,虽然是方便了,但一样也方便了别人,所以这是不对的。

主要原因是硬编码远比你想的脆弱,如果不及时更正你的习惯,这将是个很大的而且不好修复的安全隐患。

9、不恰当的测试

测试作为整个系统开发生命周期(Systems Development Life Cycle,简称SDLC)的重要一个要素,通常不需要开发团队给出太惊人的结果。但是如果在测试环节没有付出恰当的、相应的努力的话,这是说不过去的。下面的一些方法或许对你的测试团队有用,至少在你们交付产品的时候能够给用户一个好的交代。

单元测试

实物模型

综合测试

10、安全漏洞

有的时候在软件开发过程中,就会遇见如下这样的安全漏洞:

A、不同组件之间意想不到的交互作用:

a、输入不正确的验证信息;

b、SQL资料隐码攻击;

c、跨网站指令码;

d、命令植入攻击;

e、跨站请求伪造(CSRF);

B、难以实施的资源管理,包括:

a、不尊重可用内存缓冲区;

b、对外控制;

c、使用有潜在危险的功能;

11、不和客户交流

最初的合同签订后,开发公司通常会忘记每天与客户进行产品上的信息交互,以至于在交货的时候还需要进行升级。两大关键的交流点可以让你和客户保持更好的、更长的关系:

在客户开问之前,开发方应该和客户进行交流沟通。

和客户保持周期性的交流。

如果你打算写一手好程序那么你就应该 改变你对编程的看法。