每个程序员都可能犯过的10个错误!(转载)

每个程序员都可能犯过的10个错误!

2015-03-04 深度操作系统 深度操作系统

深度操作系统

微信号

功能介绍 深度操作系统——个性、时尚、前卫。deepin,为您带来海量最新资讯,与您分享更多技巧。

点击上方↑↑“深度操作系统”↑↑ 可关注我们

本文列出的10个错误,并不局限于C#,Delphi,JavaScript等——几乎涵盖了所有的编程语言。是不是大吹大擂,欢迎各位品鉴……

1.面向编译器写代码,而不是面向用户

当人们使用编译器创建自己的app时,在把自己的想法诉诸于机器代码的过程中,常常会将那些可以使得编程更为简单却又冗长的语法遗忘于脑后。

无论你使用的是单字母的标识符还是更易于人脑理解的标识符,对于编译器而言,毫无区别。编译器不在乎你写的是否是优化表达式,也不在乎你是否用括号封装了子表达式。编译器要做的就是将这些人脑可读的代码,解析为抽象的语法树,并将这些树转换成机器代码,或某种中间语言。

那么,为什么不使用更可读或者语义更明显的标识符呢——而不要仅仅是I,J或x。老实说,现在我们用来等待编译器完成转换标识符的时间几乎是微不足道。但是,这么做却可以大大减少你和其他程序员用于阅读理解这些源代码所用的时间。

还有一个类似的观点是:或许你可能已经记住了相关的运算符优先级,于是省略了表达式中一些不必要的括号,但是却没有考虑到后面的程序员有可能会误读你的代码,并就它是如何工作的作出一些无效的假设。

我的想法是,假设大家都知道,乘法(或除法)优先于加法和减法。其他任何我放到表达式中的内容我都会用上括号,以确保能真正表达我的意思,其他人也能真正理解我的想法。

有研究表明,有的代码维护所需要的时间甚至超出其编写时间的五倍以上。所以将代码写得易于阅读和理解是非常有意义的。

2.函数方法过于庞大

有一个经验法则就是,我们写的程序不应该过于庞大。而且我们也可以发现,现在方法趋向于越来越小巧——有时候仅仅只是几行代码。

从本质上说,要想快速把握程序的目的和意义,只需要一定的代码就够了。长方法不但令人难以接受,而且往往最终趋向于支离破碎。

其原因也非常简单:长方法既难以理解,又难以维护,甚至还难以正常测试。

有一个相当不错的测量方法可以衡量你的代码的复杂程度,以及出现bug的概率—— 循环复杂度。

该方法由Thomas J. McCabe Sr于1976年开发。循环复杂度使用方便简单,能让你在匆忙之中尽可能地保证代码运行正常。只需要数一数代码中‘if’语句和循环的数量,再加1,就是该方法的CC值。

当然这只是对代码执行路径数量的粗略计数。不过,如果你的某个方法其循环复杂度值大于10,我建议你重写。

3.过早的优化

这一点非常简单。当我们在编写代码的时候,有时我们会自作聪明地对某些代码过于注重细节过于精益求精,虽然看上去这些“明智”的代码比原先写的那些提高了速度,但是你忽略了一个事实,这些“明智”的代码往往是难以阅读难以理解的——而且真正节省的时间往往只有几毫秒。这就是所谓的过早的优化。

著名的计算机科学家Donald Knuth曾经说过,“过早的优化是一切罪恶的根源”。

换言之就是:我们的代码需要清晰、干净,然后再重点找出真正的瓶颈并对其进行优化。千万不要试图过早的优化。

4.使用全局变量

话说回来,有的编程语言是完全没有局部变量这个概念的,所以不得不使用全局变量。关于全局变量,虽然我们可以在子函数中使用它,但是却没办法声明这一变量只能在该函数中使用。尽管如此,全局变量依然非常受欢迎,因为我们只需声明一次,即可到处使用,太省时省力了有木有。

但是它的优点也是它的缺陷,这也是关于全局变量最糟糕的事情——我们没有办法控制它的改变,也没办法控制何时去访问变量。假设某个全局变量在调用到程序之前赋予了一个特定的值,但是很可能调用完了之后值就变了,而你却毫无察觉。

5.不进行评估

你的目标是写一个应用程序,你斗志昂扬,愈战愈勇。但是突然间,你发现了性能问题和内存不足的问题。

进一步的调查表明,尽管你的设计对于现在这样小型的用户数量、记录、条目运行良好,但是却不适合大规模的情况——Twitter就是例子。又或者它现在在你的8GB RAM和SSD的3GHz PC上运行顺畅,但一旦到普通的PC上,它会比乌龟爬还要慢吞吞。

所以,部分设计进程还是需要评估,需要一系列的封底计算。有多少用户需要同时处理多少个用户?需要处理多少记录?目标响应时间又是多少?等等。

尽量对这些类型的问题进行评估,这样就可以对应用程序中的一些技术问题做一些更进一步的决策,如不同的算法和缓存。不要什么乱七八糟的都纳入到开发中去——你还需要好好评估目标和目的。

6.大小差一错误(数组边界溢出)

这个错误基本上每一个程序员都犯过,通常在写循环的时候,由于循环变量的步长增加过多或过少,导致循环遍历元素的次数发生错误,产生数组溢出的异常。

这个错误会导致遍历数组元素时访问不存在的元素,或者遗漏应该遍历的元素。产生这个错误的原因就是你忘记了数组下标是从0开始还是从1开始了。

7.淹没异常

现在的编程语言大多使用异常系统作为错误报告技术,而不再是以往传统的传递和检查故障代码。现在的编程语言使用新的关键字来处理和捕获异常,其名称为throw、try、finally和catch等。

关于异常处理值得一提的是,它们的作用是展开堆栈,从嵌套程序自动返回,直到异常被捕获并处理。不再需要你检查错误条件,从而导致代码深陷错误测试的泥沼。

通过正确地运用异常处理,我们能够使得软件更为强大。比如说catch能让我们捕获异常,并根据异常类型执行某种行为。

关于异常处理,程序员犯的最大的错误有两种。第一种是程序员对于他们catch的异常了解得不够清楚具体。捕获过于笼统化的异常类型可能会导致你在不经意间处理掉一些最好能够保留的特定异常。而这样做,可能会导致这些异常被淹没、丢失。

第二个错误更为有害:程序员不想要任何异常离开自己的代码,因此捕获之后忽略了它们。这就是所谓的空catch块。他们可能是这样想的,只要throw某些类型的异常就可以了:于是名正言顺地忽略了这些异常。

而现实是,这可能会导致其他致命的运行时异常——如内存不足的异常,代码无效的异常等等,从而使得程序无法正常运行。因此,调整异常catch块时应尽可能的具体化。

8.纯文本格式存储密码

数据安全性是永远值得探讨的话题,其重要性是不言而喻的。在这里,我要郑重告诉你的是,千万不要将密码用纯文本格式保存。

密码的标准是,先存储经过加密后杂乱无章的原始密码,然后再输入通过相同加密方法后的杂乱的密码,看看它们是否匹配。

还不清楚这样做的害处,那么给你个提示:如果某个网站承诺,如果你忘记了原始密码,他们会给你发送电子邮件告诉你,那么远离这种网站。这可能会出现巨大的安全问题。假设有一天,该网站会被黑的话,那么你所有的登录信息都会被泄漏出去,而你除了忍气吞声惶惶而不可终日却毫无办法。所以,千万不要接触这类网站,同样的,也不要在你的app里用纯文本的格式存储密码或其他的“秘密”。

9.不验证用户输入

以前的程序是单用户的,于是我们对用户输入往往不以为然:毕竟,如果程序崩溃的话,只会影响到一个人的使用。我们的输入验证仅限于数值验证、日期检查,或其他类型的输入验证。

文本输入往往不会特别验证。不过后来出现了网页。于是,你的程序有了遍布世界的用户。而一些恶意用户则会通过输入数据到你的程序,以试图接管你的app和服务器。

新型的攻击大多是因为缺乏对用户输入的检查。其中最著名的是SQL注入,通过标记注入,不好的用户输入可能会引发XSS攻击(跨站脚本)。

这两种类型都依赖于用户提供包含了SQL或者HTML片段的文本,来作为正常表单输入的一部分。如果应用程序不验证用户输入,直接就拿来用,那么很可能就会执行篡改的SQL,或者产生一些被攻击的HTML/JavaScript。

这反过来可能会使得app崩溃,或被黑客接管。为了避免这些情况,所以我们应该时时验证或消除用户输入。

10.不与时俱进

上述这些我总结的内容或许并不新鲜——你可能已经在其他的书籍或网页上涉猎过。但是随着时代的发展,会有越来越多的新的设计和编程技术面世。

而你如果还抱着一些陈旧的逐渐在被淘汰的技术不放,不愿意学习和了解新的编程方法和技术——那么你终将会被拍死在沙滩上。对于程序员,学习是永恒的课题。例如TDD和BDD,SLAP和SOLID方法,以及各种敏捷技术,都是我们应该学习的技术。

我们应该时刻保持对最新的编程艺术和实践的同步。

来源:码农网

==============================

★点击右上角【…】分享至朋友圈;

★点击底部【阅读原文】查看更多信息。

深度操作系统

个性·时尚·前卫。

deepin,为您带来最新行业资讯。

【欢迎关注】

微信号:深度操作系统

新浪微博:@深度操作系统

官方网站:http://www.linuxdeepin.com/

时间: 2024-10-30 11:47:01

每个程序员都可能犯过的10个错误!(转载)的相关文章

每个程序员都可能犯过的10个错误

本文列出的10个错误,并不局限于C#.Java.Delphi.JavaScript等——几乎涵盖了所有的编程语言.是不是大吹大擂,欢迎各位品鉴…… 1.面向编译器写代码,而不是面向用户 当人们使用编译器创建自己的App时,在把自己的想法诉诸于机器代码的过程中,常常会将那些可以使得编程更为简单却又冗长的语法遗忘于脑后.无论你使用的是单字母的标识符还是更易于人脑理解的标识符,对于编译器而言,毫无区别.编译器不在乎你写的是否是优化表达式,也不在乎你是否用括号封装了子表达式.编译器要做的就是将这些人脑可

PHP程序员最常犯的11个MySQL错误

对于大多数web应用来说,数据库都是一个十分基础性的部分.如果你在使用PHP,那么你很可能也在使用MySQL—LAMP系列中举足轻重的一份子. 对于很多新手们来说,使用PHP可以在短短几个小时之内轻松地写出具有特定功能的代码.但是,构建一个稳定可靠的数据库却需要花上一些时日和相关技能.下面列举了我曾经犯过的最严重的11个MySQL相关的错误(有些同样也反映在其他语言/数据库的使用上). 1.使用MyISAM而不是InnoDB MySQL有很多数据库引擎,但是你最可能碰到的就是MyISAM和Inn

每一个程序员都应当了解的11句话

每一个程序员都应当了解的11句话,你最同意哪一句? 1. 技术只是解决问题的选择,而不是解决问题的根本 我们可以因为掌握了最新的 JavaScript 框架 ahem.Angular 的 IoC 容器技术或者某些编程语言甚至操作系统而欢欣雀跃,但是这些东西并不是作为程序员的我们用来解决问题的根本——它们只是用于帮助我们解决问题的简单工具. 我们必须非常谨慎,不要对某项正好喜欢或者正好很火的特定技术走火入魔.否则,我们将进入这样的思维怪圈:把掌握的那项技术比做是锤子,在思考问题时,会自然的把所有的

每个程序员都必读的12篇文章

英文原文:10 Articles Every Programmer Must Read 作为一名 Java 程序员和软件开发人员,那些每个程序员都应该知道的 XXX 的文章教会了我不少东西,它们提供了某个特定领域的一些实用的并且有深度的信息,这些东西通常很难找到.在我学习的过程中我读到过许多非常有用的文章,我把它们添加到了书签里,方便以后阅读或者引用.我个人认为所有开发人员都能从这些文章中受益,因此我也写了篇"每个程序员都应该了解的"文章,准备分享给你们.这是我的个人收藏.在这篇文章中

并不是所有程序员都适合做管理

很多程序员都想转管理.做管理表面很风光,因为社会普遍会对管理者会高看一眼,工作内容也多是让别人干活,不用自己亲自动手那么辛苦,最后拿的薪水却比实际干活的人还高. 但权力有多大,责任压力就有多大,管理者要每天面对各种杂事,经常被各种电话邮件打断,很难一门心思的专注做事,团队项目失败,管理者要承担责任,团队成员犯错,管理者要承担连带责任. 那么程序员如何判断自己是否适合做管理呢? 1.要有大局观,团队意识,不能只关心技术细节. 2.习惯做发动机,做整个团队的引擎,驱动着下面成员转动,给团队成员安排任

C# 程序员最常犯的 10 个错误

关于C# C#是达成微软公共语言运行库(CLR)的少数语言中的一种.达成CLR的语言可以受益于其带来的特性,如跨语言集成.异常处理.安全性增强.部件组合的简易模型以及调试和分析服务.作为现代的CLR语言,C#是应用最为广泛的,其应用场景针对Windows桌面.移动手机以及服务器环境等复杂.专业的开发项目. C#是种面向对象的强类型语言.C#在编译和运行时都有的强类型检查,使在大多数典型的编程错误能够被尽早地发现,而且位置定位相当精准.相比于那些不拘泥类型,在违规操作很久后才报出可追踪到莫名其妙错

[注]十大编程禁忌 -- 程序员都必须克服

程序员在编程的时候难免会犯错误,但如果不从错误中吸取教训,那么习惯成自然,你会经常犯错的.从错误中不断的学习,锻炼好的行为习惯有助于事业上的稳定. 这就是我们如何将小麦从糟糠中区别出来以及如何避免编程禁忌的绝佳经验.此外,最重要的就是可以为客户带来更好的用户体验. 1. 不提升非技术技能 我们认为非技术技能是项目成功的主要因素.这些非技术技能也可以称之为“软技能”,总体上来说,它已经被公司证明为能够驾驭企业和客户之间的长期商业关系,因此也能决定公司的成长发展路径.一些关键的软技能指标包括: a.

每个程序员都必读的10篇文章

作为一名Java程序员和软件开发人员,那些每个程序员都应该知道的XXX的文章教会了我不少东西,它们提供了某个特定领域的一些实用的并且有深度的信息,这些东西通常很难找到.在我学习的过程中我读到过许多非常有用的文章,我把它们添加到了书签里,方便以后阅读或者引用.我个人认为所有开发人员都能从这些文章中受益,因此我也写了篇“每个程序员都应该了解的”文章,准备分享给你们.这是我的个人收藏.在这篇文章中,你会看到每个程序员都应该了解的一些经典文章,涵盖了内存,unicode,浮点数,网络,面向对象设计,时间

每个程序员都应该了解的十一句话

 文来自泡面吧 侵删 1.技术只是解决问题的选择,而不是解决问题的根本 我们可以因为掌握了最新的JavaScript框架ahem.Angular的IoC容器技术或者某些编程语言甚至操作系统而欢欣雀跃,但是这些东西并不是作为程序员的我们用来解决问题的根本--它们只是用于帮助我们解决问题的简单工具. 我们必须非常谨慎,不要对某项正好喜欢或者正好很火的特定技术走火入魔.否则,我们将进入这样的思维怪圈:把掌握的那项技术比做是锤子,在思考问题时,会自然的把所有的问题都想象成是锤子可以解决的钉子. 2.聪明