命名约定前后矛盾、版本兼容相互冲突，PHP语言在各个层面上都给开发人员带来了诡异而难解的谜局——这就是我们今天要讨论的话题。我们真的对PHP深恶痛绝吗?不，当然不是。如果真是这样，我们就不会如此广泛地使用Drupal、WordPress以及其它一些同类框架。假设我们真的讨厌PHP，那么最直接的办法是转向Java而非在这里放什么厥词。不过需要提醒各位拥护者的是，也别因为熟悉而对PHP的那些缺陷视而不见。
转换令人头痛
在利用PHP进行项目创建的过程中，最大的挑战之一在于牢记我们哪些时候需要输入HTML、而哪些时代需要输入PHP代码。将二者相结合正是PHP语言的一大卖点，但要充分发挥其优势却着实不是易事。当我们查看某个文件并关注其中的代码时，首先需要搞清楚的就是——那些迫使我们不得不从HTML编写转向创建服务器指令的标签都在哪里?各位必须要高度重视这些标签，因为只有这样我们才能将代码与标记整合起来并使其顺畅运作。当然，大多数情况下它只会让人晕头转向。
标记的迷宫
将服务器指令与浏览器标记结合起来实在是一种失误。在Java这方面，其研发团队严格遵循着MVC模式。数据模型被归于一个文件中，用于控制视图的布局结构被归于另外的文件中，而用于构建控制器的逻辑也拥有自己的归属文件。将这些条目区分并隔离开来能够让整个项目变得更有条理。但在PHP方面，最基本的设计思路就是开发者应当将HTML标记与服务器的控制器逻辑杂糅在一起。虽然我们不是没办法把它们区分开——大多数人也确实是这样做的——不过一旦开始专门处理这项任务，很多朋友可能会像我们一样问自己“为什么我们非要用PHP不可?”
命名约定的不一致性与特殊性
大家知不知道我们什么时候需要用到下划线符号?可以看到，base64_encode方法中用到了下划线，但urlencode则没有。此外，php_uname这一名称中使用了下划线，而phpversion则没有。为什么会这样?有没有人考虑过这个问题?大家有没有编辑过API?
与此同时，strcmp函数是不能够大写的，但strcasecmp却可以。另外，strpos不能大写，stripos则可以。到底是其中的字母“i”决定了能否大写，还是函数整体名称决定的?谁能记得住这么多乱七八糟的规则?当然，开发者们必须得记清楚。
灾难般的排序
我们到底需要多少种排序函数?Java拥有一项基础排序函数外加一个适用于所有对象的简单接口。如果大家希望使用其它算法、动手添加进去即可，而且大多数情况下标准函数已经完全够用。而在PHP这边，光是排序函数就能列出一条长长的清单：usort、sort、uksort以及array_sort等等(请注意，其中有一些还需要用到下划线)。所以，请大家马上把这些内容记到小本上，并祈祷自己在实际使用时不会搞混吧。
开源存在一定局限性
PHP也许确实拥有开源的诸多优势，但缓存等卓越功能却只存在于商用版本当中。当然，这就是现实社会，毕竟Zend需要借此赚取利润。再有，该公司还需要通过向特定用户群体出售最佳版本的方式支持整个PHP项目。抱怨这一点就像抱怨地心引力带来的不便一样，正确但却毫无意义——地球就在那里，根本不鸟你喜不喜欢。请大家活得理性一些，别总幻想着人们都能活在乌托邦式的开源环境当中。
糟糕的命名空间
大家有没有创建自己函数的打算?如果有，请首先确定到底要使用PHP 5.3或者其后续版本，因为这里正是命名空间出现的分界线。如果大家希望使用早期版本，则必须确保编码内容与库之间不存在冲突——毕竟在早期发展阶段，PHP中的所有内容都具备全局化属性。如果大家决定使用PHP 5.3并接受命名空间的加入，那么请作好准备迎接“反斜杠”——一个丑陋的标点符号——的降临。
糟糕的type安全
这个问题简直可怕，首先举个PHP程序员们喜闻乐见的例子：
(string)"false" == (int)0
请注意，这并不属于那种某些PHP支持者所争论的“函数副作用”的典型情况。毕竟JavaScript当中也包含着大量由于type转换所引发的同类情况。事实上，这一行想表达的是：左侧为字符串，右侧为一个整数。只不过左侧与右侧内容完全相等。照这样说来，如果让PHP的设计者负责管理、世界上的每个人都能彼此和睦相处。
选择太多，冗余太多
PHP语言的一大特色就是可做的事太多，做事的途径同样太多。每一行命令的结尾都可以通过数字符号或者双斜线来进行注释。无论是浮点数字还是双精度数字都代表着同样的含义。简单的设计往往会被人们所忽略，因为大家在代码贡献过程中喜欢添加自己的小特性。这有点像依靠委员会体系进行设计，只不过该委员会从来没考虑到过把其中的差异性剔除掉。
诡异的变量命名规则
把美元符号作为前缀实在不是个好主意。也许强制性地在所有变量前添加这个符号是为了更轻松地将其插入到模板当中，但这样说来常数内容也同样需要这么个符号啊——为什么实际上却用不着呢?
CPU资源争夺战
对于32位计算设备来说，整数数值过大始终是个无法回避的难题。不过在另一方面，64位设备却不会受此影响，也就是说代码在不同设备上的运行状态是不同的。大家可以在自己的笔记本上测试一下，我可以保证事实绝对是如此。但一旦把运行平台转换成服务器，情况则会再度变化。这时如果大家希望重现自己台式机上的错误，结果恐怕要令各位失望。惟一的好消息是，32位设备将很可能最终消失。
SQL注入
将SQL注入这一安全漏洞的主要形式之一归咎于PHP确实有失公允。人们在其它语言当中同样会不慎输入奇怪的SQL字符串。之所以将其纳入文章，主要是考虑到PHP语言更容易让该漏洞攫取数据并发送至MySQL——简单是轻而易举。虽然新手在使用任何一种语言时都可能犯下同样的错误，但这类情况在PHP中出现的机率明显要高得多得多。
不兼容式的变更太多太多
不同版本之间存在巨大差异，兼容性问题也绝不是小事。以Java或者JavaScript为代表的编程语言在快速发展的同时也牺牲了向下兼容的特性。事实上，老代码在新设备上无法运行的问题并不少见。但这一切与PHP的情况其实不尽相同。在PHP方面，不同版本之间往往差别巨大，因此大家只能祈祷自己的服务器已经安装了正确的版本，否则只有在出现严重问题时才能意识到大事不妙。总而言之，在查看服务器上是否有项目需要升级时，请优先把目光对准PHP。
当前版块2016年12月1日之前所发主题贴不支持回复！详情请点击此处>>
客户端下载
发表于 2015-6-3 16:00
