为什么你是不合格的PHP程序员？

 

每个人都有坏习惯。本文将列出一系列值得我们马上检查、评估和纠正的错误实践。

 

你以为你是哪根葱？

“每次我打开一个别人的项目，就像是经历一次末日之旅一样，其中遍布各种陷阱，神秘代码，在这之上修改一行代码都会影响到整个项目。”
当我们自己是错的时候，只会想想要是我的话会怎么写这段代码，然后深吸一口气，挽起袖子，深入到项目中开始研究起来。
但是当我们是对的时候，好吧，情况就完全不同了。
我们第一个念头就是“这傻X以为自己是谁，乱写代码”，什么样的程序员会弄这么个项目？
 

答案会吓到你

你的直觉会告诉假设写这项目的哥们要么是个新手，要么是个傻X。但事实却不总是这样。

我的推测是这些可怕的代码是许多的小捷径或者让步堆积而成的毫无经验或愚蠢的产品。更可怕的是这是由像你们这样聪明的，博学的人写的。他们只是由于懒惰或者想快速的把代码写完而导致了你看到的噩梦般的代码。

更可怕的是在你的代码移交到某人手里的时候

 

你比那好多了，朋友！

这不是要要求你马上复查你目前的代码，确信自己没有写什么臭代码让别人睡不着，呵呵。
让我们花个几分钟来仔细看看一些普遍的捷径(shortcuts)，让步(concessions)和其他一些错误实践，从而保证我们的项目不会令人心生恐惧。
 
========================貌似前面都是废话啊=============================================
 

在你开始写代码之前，没有任何计划

在你写任何代码之前，你必须订好整个计划。这会帮助你步入正轨且防止写一些以后会让你自己和其他人感到困惑的想当然的代码。
一个节省我时间的方法是在代码开头先写一段大纲，注释掉：
[php] view plaincopy
  1. <?php  
  2.   
  3. // Include necessary data  
  4.   
  5. // Initialize the database connection  
  6.   
  7. // Include the common header markup  
  8.   
  9. // Determine the page variables from the POST data  
  10.   
  11. // Load the proper database info using the page vairiables  
  12.   
  13. // Loop through the loaded rows  
  14.   
  15.     // Format the images for display  
  16.   
  17.     // Create a permalink  
  18.   
  19.     // Format the entry for display  
  20.   
  21.     // Add the formatted entry to the entry array  
  22.   
  23. // Collapse the entry array into page-ready markup  
  24.   
  25. // Output the entries  
  26.   
  27. // Include the common footer markup  

就像你看到的，没有写代码之前，我已经几乎确切的知道这个文件要写哪些代码了。
最好就是你可以用这样的方式为整个应用程序做个计划，而且如果你觉得有个功能需要移动到另一个应用程序中，你只要修改下注释就可以了。
在你实际应用当中需要做一些变化，但是这会让你的项目组织能力得到提升。

“注意：这里有些注释是不必要的；有些是需要改的；有些我们会希望增加的。这就像为一篇论文写个大纲或者写个杂货店清单一样：它能以正确的方式完成你的工作。”

 

没有一点注释

还要把这个列出来，我挺难过的。像注释这么自然的事情，我们不应该还要提醒彼此去做。
我碰到的最糟糕的代码是只有很少注释或根本没有注释的。这不但让我花了很多时间去了解熟悉这个项目，而且必定会碰到一个让我很不解，不知道哪个地方会使用到的代码块。然后，假设我做完了重构，我或许将不经意间破坏了这个程序，因为我根本没有遇到需要使用到这段代码的地方。
 
注：这里是个长句，不是特别明白，望高人指点。(This not only adds a good chunk of time to my initial familiarization with the project, but it pretty much guarantees that a fix made using an unconventional method out of necessity will confuse me.Then, if I end up doing any refactoring, I’ll inadvertently break the app because I haven’t encountered the extenuating circumstances that required the fix.)
 
这个过程将会费我10分钟到6小时不等的时间。
所以大声说出来：
“我，【你的名字】，特此声明，将在任何我写的代码功能不那么明显的情况下都会写上注释。”
“那么明显”的意思参考那些不能自解释（因为不是那么有理由这么做）或者不是为了完成一个极度简单的任务写的代码。这么说吧：如果你不得不停下来花几秒钟时间思考你的意图，这就值得去写个简短的注释了。
为了说明我的意思，我将举个我在最近写给初学者的文章中的例子。
[php] view plaincopy
  1. $pieces = explode('.', $image_name);  
  2. $extension = array_pop($pieces);  

这段代码做了什么？你是否要停下来想想呢？你是不是还不很确定$extension变量存储的是什么值？
在看看下面这段有点小注释的：
[php] view plaincopy
  1. // Get the extension off the image filename  
  2. $pieces = explode('.', $image_name);  
  3. $extension = array_pop($pieces);  

现在扫一眼注释，再扫一眼代码，应该就很清楚了吧。
这可能只是让你少想了5秒钟，但是如果你是在写一个复杂的程序的话，5秒5秒加起来就很多了。
那么别找借口了。写下那该死的注释吧。

你为了代码简短而牺牲了清晰度

一个普遍的诱惑是以更少的代码去解决问题，但是这种诱惑就像是你有两条内裤，可以拿到洗衣店洗更快点，但是由此引发的问题远大与你的收益。
一个很好的为了减少代码而减少代码的例子就是没意义的变量命名（比如$a -- $a到底啥意思？）和省略大括号。
省略大括号是我经常抱怨的问题。如果不喜欢大括号的话，可以使用python，PHP中没有它们很容易搞混结构。
例如下面这个省略大括号的例子：
[php] view plaincopy
  1. <?php  
  2.   
  3. $foo = 8;  
  4.   
  5. if( $foo<10 )  
  6.     if( $foo>5 )  
  7.         echo "Greater than 5!";  
  8.     else  
  9.         echo "Less than 5!";  
  10. else  
  11.     echo "Greater than 10!";  
  12.     echo "<br />Another note.";  
看上去好像最后一行只有在$foo>=10的情况下才会运行，但是实际情况是根本和$foo无关，怎么样最后一行都会运行。
稍微仔细点看你应该就能看出来。
那你应该在这上面浪费你宝贵的时间吗？绝对不应该啊！
下面我们增加个几行大括号，看上去就清晰多了：
[php] view plaincopy
  1. <?php  
  2.   
  3. $foo = 8;  
  4.   
  5. if( $foo<10 )  
  6. {  
  7.     if( $foo>5 )  
  8.     {  
  9.         echo "Greater than 5!";  
  10.     }  
  11.     else  
  12.     {  
  13.         echo "Less than 5!";  
  14.     }  
  15. }  
  16. else  
  17. {  
  18.     echo "Greater than 10!";  
  19. }  
  20. echo "<br />Another note.";  
确实，保持你的代码简洁是个好事情，但是不要以牺牲易读性为代价。。。

你没有按照一定的格式编码

 
以你自己的审美观点去写你的代码，你自己是高兴了，但其他人就不那么想了。
还是以一个标准的格式去写代码（个人建议用这个标准），并且坚持使用，别变来变去。
相信我，有次我整了个特别的代码格式，就跟我的签名似的，个性的不行，后来我被迫浪费好几个小时去重新修改过。个性也分个时间地点啊，亲。
对于编程来说，就像学语文，啥语法，标点都是为了更清楚的明白到底在讲什么。
 

重复编码

只要你在整个应用程序中，更新一处代码，跟着就有其他地方要做同样修改的话，就需要重构了。试着把它写成一个函数，几个地方只要调用，修改只在一个文件中。
 

不遵循一个开发模式

当你编码的时候，总是应该遵循一个结构。我的意思不是说让你一定要使用MVC模式或其他同样的东东，但我确实强调你应该知道怎样组织各个组件结构，哪些代码应该放在哪里。
遵循一个有逻辑的开发模式，许多部分已经都确定了。其他人使用你的代码的时，不用去猜也知道哪个功能在哪个文件夹下。
这不需要花你太多时间，却能让你在面对大的项目时，能更清晰的组织结构。
 

太喜欢秀自己的独门秘技

灵活的解决方案和过度复杂的解决方案是有个分界线的。
你总是会想在项目中尝试你学到的新的技术，但是在简单的方案就已经足够的时候，我们就一定不要让它复杂化。
一般来说，最简单的方案通常就是最适合的方案。从A到B有条直路，你一定要绕个圈再到B，或许你觉得很有意思，但是对于项目来说毫无益处。
你的秘技好像很不错，但是很可能给在项目中的其他成员带来困扰。这不是说别人没有你聪明，这只能说明他们没有看过你这个秘技或者觉得根本没有必要杀鸡用牛刀。
但是也别灰心，好学的劲头还是要保留的，只是要记住别把简单的事情复杂话。
我们都不是完美的，但是我们要不断努力，尽量做到最好。
 
=============================这是前半部分=========================
怕太多大家也就不看了，呵呵，明天继续翻译后面部分。
 
英语水平有限，翻译中必然有许多不妥之处，抱歉。希望大家交流交流，给点意见。

作   者：OpenGis2012
出   处：http://www.cnblogs.com/opengis/
个人站:  http://gis-open-source-ogc.com/
欢迎任何形式的转载，但请务必注明出处。

posted @ 2012-03-21 13:52  opengis2012  Views(1123)  Comments(2)  Edit  收藏  举报
Using GIS to Change the World! www.gis-open-source-ogc.com