在平时的编程工作中,大多数程序员很少会关心细节问题,本文作者跨越多个语言,为大家总结了20条常规陷阱,并提供了很好的解决方案,供大家参考学习。
不管你现在的编程技能有多么的高超,曾经你也是个亦步亦趋,不断的学习的初学者。在编程这条曲折的道路上,我想你肯定犯过一些低级的错误、遇见过一些普通的编码陷阱。本文作者跨越多个语言,为大家总结了20条常规陷阱,并提供了解决方案。
JavaScript篇
1.不必要的DOM操作
例如下面这段代码:
- // anti-pattern
- for (var i = 0; i < 100; i++){
- var li = $("<li>").html("This is list item #" + (i+1));
- $("#someUL").append(li);
- }
这段代码对DOM进行了100次修改,并且创建了100个不必要的jQuery对象。正确的做法是使用一个文档片段,或者创建一个字符串,把100个<li>元素赋给该字符串。然后附加到HTML中。这样就只需运行DOM一次,代码如下:
- var liststring = "";
- for (var i = 100; i > 0; i--){
- liststring += "<li>This is list item #" + (99- i);
- }
- document.getElementById("someUL").innerHTML(liststring);
正如上面所描述的一样,下面再提供一个方式,使用数组:
- var liststring = "<li>"
- var lis = [];
- for (var i = 100; i > 0; i--){
- lis.push("This is list item #" + (99- i));
- }
- liststring += lis.join("</li><li>") + "</li>";
- document.getElementById("someUL").innerHTML(liststring);
这是在JavaScript创建重复HTML最快最简单的方法,无需使用模板库或框架。
2.不一致的变量名和函数名
这个问题是非常重要的,尤其当你在别人的代码上工作时,一定要保持标识符(变量名和函数名)一致,例如下面这段代码:
- var foo = "bar";
- var plant = "green";
- var car = "red";
通常,人们并不会设置变量名叫Something,这涉及到命名规则问题,命名应清晰明了,一目了然。很多编程语言地变量命名都使用大写。
下面是对函数的命名:
- function subtractFive(number){
- return number - 5;
- }
语法结构清晰并且能起到解释性功能。
例如想要对给定的数字加5,仍采用上述命名模式,比如:
- function addFive(number){
- return number + 5;
- }
有时,你会根据返回值命名,例如该函数要返回一个HTML字符串,那么可以命名为getTweetHTML(),如果函数只是做一些操作,无需返回值,那么可以在前面加一个do前缀。例如doFetchTweets()。
构造函数通常会遵循类原则,大写第一个字母:
- function Dog(color){
- this.color = color;
- }
命名应带有描述性,比如操作型的函数在前面加do,另外要具备可读性和提示性。
3.在for...Loops中使用hasOwnProperty()方法
JavaScript数组是没有关联的,可以把它当做哈希表,使用循环来遍历对象属性:
- for (var prop in someObject) {
- alert(someObject[prop]); // alert's value of property
- }
然而,存在的问题是for...in loop是在对象属性链上遍历每个枚举类型的属性,如果你只想使用对象实际拥有的属性,这可能有问题的。那怎么解决呢?你可以使用hasOwnProperty()方法。代码如下:
- for (var prop in someObject) {
- if (someObject.hasOwnProperty(prop)) {
- alert(someObject[prop]); // alert's value of property
- }
- }
4.比较布尔值
把布尔值作为条件进行比较,其实这是在浪费电脑的计算时间。看下面这个例子吧:
- if (foo == true) {
- // do something for true
- } else {
- // do something for false
- }
其实foo==true这个比较完全是多余的,因为foo已经是布尔类型。直接这样写就行:
- if (foo) {
- // do something for true
- } else {
- // do something for false
- }
又或者这样写:
- if (!foo) {
- // do something if foo is false
- } else {
- // do something if foo is true
- }
5.事件绑定
在JavaScript中,事件是个复杂的问题。事件冒泡(event bubbling)和委托正在取代内联事件(inline onclick)操作(一些特殊的“初始页”除外)。
假设你有一个图片网格,需要启动一个modal lightbox窗口。千万不要采取下面的做法,示例采用的是jQuery,如果你使用相似的库或者其他,冒泡机制也同样适合传统的JavaScript。
相关的HTML代码:
- <div id="grid-container">
- <a href="someimage.jpg"><img src="someimage-thumb.jpg"></a>
- <a href="someimage.jpg"><img src="someimage-thumb.jpg"></a>
- <a href="someimage.jpg"><img src="someimage-thumb.jpg"></a>
- ...
- </div>
不好的JavaScript写法:
- $('a').on('click', function() {
- callLightbox(this);
- });
这段代码假设调用lightbox,里面传递一个anchor元素并且引用全屏图片。与其绑定每个anchor元素还不如直接使用#grid-container元素。
- $("#grid-container").on("click", "a", function(event) {
- callLightbox(event.target);
- });
在这段代码中,this和event.target都表示anchor元素。同样你也可以在任何父元素上使用。只要保证所定义的元素是事件目标就行(event's target)。
6.避免三元冗余
在JavaScript和PHP中,过度使用三元语句是很常见的事情:
- // javascript
- return foo.toString() !== "" ? true : false;
- // php
- return (something()) ? true : false;
条件判断的返回值永远只有false和true,言外之意就是你无需把true和false显示添加到三元运算中。相反,你只需简单的返回条件:
- // javascript
- return foo.toString() !== "";
- // php
- return something();
PHP篇
7.适当的时候使用三元操作
If...else语句是大多数语言的重要组成部分。但有些简单的事情,比如根据条件进行赋值,你很有可能会这样写:
- if ($greeting)
- {
- $post->message = 'Hello';
- }
- else
- {
- $post->message = 'Goodbye';
- }
其实使用三元操作只需一行代码就可以搞定,并保持了良好的可读性:
- $post->message = $greeting ? 'Hello' : 'Goodbye';
8.抛出异常,而不是采用盗梦空间式的嵌套(Inception-Style Nesting)
多层次的嵌套是丑陋的、难以维护和不可读的。下面的代码是个简单的例子,但是随着时间的推移会变得更糟:
- // anti-pattern
- $error_message = null;
- if ($this->form_validation->run())
- {
- if ($this->upload->do_upload())
- {
- $image = $this->upload->get_info();
- if ( ! $this->image->create_thumbnail($image['file_name'], 300, 150))
- {
- $error_message = 'There was an error creating the thumbnail.';
- }
- }
- else
- {
- $error_message = 'There was an error uploading the image.';
- }
- }
- else
- {
- $error_message = $this->form_validation->error_string();
- }
- // Show error messages
- if ($error_message !== null)
- {
- $this->load->view('form', array(
- 'error' => $error_message,
- ));
- }
- // Save the page
- else
- {
- $some_data['image'] = $image['file_name'];
- $this->some_model->save($some_data);
- }
如此凌乱的代码,是否该整理下呢。建议大家使用异常这个清洁剂:
- try
- {
- if ( ! $this->form_validation->run())
- {
- throw new Exception($this->form_validation->error_string());
- }
- if ( ! $this->upload->do_upload())
- {
- throw new Exception('There was an error uploading the image.');
- }
- $image = $this->upload->get_info();
- if ( ! $this->image->create_thumbnail($image['file_name'], 300, 150))
- {
- throw new Exception('There was an error creating the thumbnail.');
- }
- }
- // Show error messages
- catch (Exception $e)
- {
- $this->load->view('form', array(
- 'error' => $e->getMessage(),
- ));
- // Stop method execution with return, or use exit
- return;
- }
- // Got this far, must not have any trouble
- $some_data['image'] = $image['file_name'];
- $this->some_model->save($some_data);
虽然代码行数并未改变,但它拥有更好的可维护性和可读性。尽量保持代码简单。
9.False——Happy方法
Ruby或Python开发者常常关注一些微小的异常,这是相当不错的事情。如果有地方出错就会抛出异常并且你会立即知道问题所在。
在PHP中,特别是使用比较老的框架,如CodeIgniter,与抛出异常相比,它仅仅返回一个flase值,并且把错误字符串分配给其他一些属性。这就驱使你使用get_error()方法。
Exception-happy远远好于false-happy。如果代码里面存在错误(例如不能连上S3下载图片,或者值为空等),然后抛出一个异常,你也可以通过继承Exception类来抛出特定的异常类型,例如:
- class CustomException extends Exception {}
抛出自定义类型异常会让调试变得更加容易。
10.Use Guard Clauses
使用if语句控制函数或方法的执行路径是很常见的事情,如果if条件为true就执行if里面的代码,否则就执行else里面的代码。例如下面这段代码:
- function someFunction($param) {
- if ($param == 'OK') {
- $this->doSomething();
- return true;
- } else {
- return false;
- }
- }
这是很常见的意大利面条式的代码,通过转换条件对上述代码进行优化,不仅可以增加其可读性,看起来还会更加简单,如下:
- function someFunction($param) {
- if ($param != 'OK') return false;
- $this->doSomething();
- return true;
- }
11.使用While进行简单的迭代
使用for进行循环是很常见的事情:
- for (var i = 0; i < x; i++) {
- ...
- }
当然,for循环也有许多优势,但是对于一些的循环,使用while或许会更好:
- var i = x;
- while (i--) {
- ...
- }
12.保持方法可维护性
让我们来看一下这个方法:
- class SomeClass {
- function monsterMethod() {
- if($weArePilots) {
- $this->goAndDressUp();
- $this->washYourTeeth();
- $this->cleanYourWeapon();
- $this->takeYourHelmet();
- if($this->helmetDoesNotFit())
- $this->takeAHat();
- else
- $this->installHelmet();
- $this->chekcYourKnife();
- if($this->myAirplain() == "F22")
- $this->goToArmyAirport();
- else
- $this->goToCivilianAirport();
- $this->aim();
- $this->prepare();
- $this->fire();
- }
- }
- }
再看如下代码:
- class SomeClass {
- function monsterMethod() {
- if($weArePilots) {
- $this->prepareYourself();
- $this->tryHelmet();
- $this->findYourAirport();
- $this->fightEnemy();
- }
- }
- private function prepareYourself() {
- $this->goAndDressUp();
- $this->washYourTeeth();
- $this->cleanYourWeapon();
- $this->chekcYourKnife();
- }
- private function tryHelmet() {
- $this->takeYourHelmet();
- if($this->helmetDoesNotFit())
- $this->takeAHat();
- else
- $this->installHelmet();
- }
- private function findYourAirport() {
- if($this->myAirplain() == "F22")
- $this->goToArmyAirport();
- else
- $this->goToCivilianAirport();
- }
- private function fightEnemy() {
- $this->aim();
- $this->prepare();
- $this->fire();
- }
- }
对比两段代码,第二段代码更加简洁、可读和可维护。
13.避免深层嵌套
太多层的嵌套会让代码很难阅读、理解和维护。看看下面的代码:
- function doSomething() {
- if ($someCondition) {
- if ($someOtherCondition) {
- if ($yetSomeOtherCondition) {
- doSomethingSpecial();
- }
- doSomethingElse();
- }
- }
- }
条件里面又嵌套多个条件,通过转换条件,我们对代码进行了调整:
- function doSomething() {
- if (!$someCondition) {
- return false;
- }
- if (!$someOtherCondition) {
- return false;
- }
- if ($yetSomeOtherCondition) {
- doSomethingSpecial();
- }
- doSomethingElse();
- }
相对于前面的代码,这段代码简洁了很多,并且所实现的功能也是一样的。
当你在if里面使用嵌套,请仔细检查代码,里面可能同时执行多个方法,例如下面这段代码:
- function someFunc() {
- if($oneThing) {
- $this->doSomething();
- if($anotherThing)
- $this->doSomethingElse();
- }
- }
这种情况下,可以把嵌套代码提取出来:
- function someFunc() {
- if($oneThing) {
- $this->doSomething();
- $this->doAnotherThing($anotherThing);
- }
- }
- private doAnotherThing($anotherThing) {
- if($anotherThing)
- $this->doSomethingElse();
- }
14.避免使用匿名数字和字符串(Avoid Magic Numbers and Strings)
使用匿名数字和字符串是有害无益的,在代码里定义需要使用的变量和常量。比如下面这段代码:
- function someFunct() {
- $this->order->set(23);
- $this->order->addProduct('superComputer');
- $this->shoppingList->add('superComputer');
- }
给23和“superComputer”赋予相应意义的变量名:
- function someFunct() {
- $orderId = 23;
- $selectedProductName = 'superComputer';
- $this->order->set($orderId);
- $this->order->addProduct($selectedProductName);
- $this->shoppingList->add($selectedProductName);
- }
可能会有人认为,一些无意义的变量尽量少定义,虽然它们对性能的影响是微不足道的。但可读性永远处于优先地位。请记住:不要随便优化性能,除非你知道为什么。
15.使用Built-in数组函数
使用built-in函数来代替foreach()
差的代码:
- foreach (&$myArray as $key =>$element) {
- if ($element > 5) unset ($myArray[$key]);
- }
改进后的代码:
- $myArray = array_filter($myArray, function ($element) { return $element <= 5;});
PHP里面提供了许多数组方法。起初会混淆,但是试着花时间好好学学它们。
16.不要过度使用变量
大家在开发过程中很容易使用变量,但请记住,变量是需要存储在内存中的。看下面这段代码:
- public function get_posts() {
- $query = $this->db->get('posts');
- $result = $query->result();
- return $result;
- }
$result变量其实是不需要的。
- public function get_posts() {
- $query = $this->db->get('posts');
- return $query->result();
- }
虽然这些差别都是微不足道的,但对于养成良好的编码习惯还是 很重要的。
通用篇
17.依赖数据库引擎
使用数据库来专门处理数据会让你的程序更高效。
例如,在大多数情况下,你可以避免冗余的数据查询。大多数的plug-and-play用户管理脚本在用户注册时都使用了两次数据查询:先检查用户名/邮件是否存在,另外再把用户信息插入到数据库中。一个比较好的做法是在数据库中设置username字段为UNIQUE,然后你可以利用本地的MySQL函数来检查用户名是否存在,然后添加进去。
18.正确命名变量
使用x、y、z命名变量的时代已经结束(除非是处理一个坐标系统)。变量是你逻辑代码的重要组成部分。不想键入长名字吗?获取一个好的IDE吧,使用IDE只需一眨眼的功夫就可以完成变量命名。
19.方法表示动作
见名知意,看到方法名字就知道它执行了哪些动作。使用一个短的,但具有描述性的范围命名(例如:public methods即可这样命名);使用一个长的名字,并且可以更加详细的描述(例如:定义private/protected methods)。这样会让你的代码更加可读可写。
当然也要避免用非英语来进行命名。例如使用“做些什麼()”或者делатьчтото()命名,简直是糟透了的命名。对于其他程序员来说,真的很难理解。尤其是在一个团队里,请记住,让你命名更加规范些吧!
20.结构的定义
最后,我们来说一下代码结构,从可读性和可维护性来讲,代码结构也是相当重要的,下面我们从两方面来讲:
- 首行缩进4字节或2个标签宽度。
- 设置合理的线宽(line-width)并且保持。一行只有40个字节?我们已经不是70年代的人了。一行限制在120个字节,并且在屏幕上放一个标签,并且驱使IDE保持。
结论
发生错误不要紧,关键是要总结错误,并且从中吸取教训,只有不断总结和学习,才能让你的编程之路走的更远。
来自:20 All Too Common Coding Pitfalls For Beginners
转载自:http://www.csdn.net/article/2012-11-19/2811978-20-All-Too-Common-Coding-Pitfalls-For-Be