好的代码组织方式只是为了更好看吗？

程序猿队伍里面不乏【差不多】先生：代码写出来能用就行了；开发环境能用就行了；上线前随便测测就行了；你要我再给你就行了...这些态度不仅恼人，而且对于产品质量、团队协作来说都是危害甚大，这在初创项目中结果特别明显。今天只谈代码，为啥捏？因为有个槽它不吐不快啊！作者也算见过点世面的了，但是还是被恼到了。

话说最近作者被派到了一个活儿，需要使用NetSuite的API来自动将网站的客户导入NetSuite系统里管理。NetSuite在CRM系统里也算个比较知名的大牌了，据说是Oracle传授的管理经验，功能也着实强大。然后作者就开始研究SuiteTalk PHP Toolkit，看了半天的文档，大概明白了一些业务流程做了一些准备工作，就等着用这API进行神圣的***次Web Service交互。洋洋洒洒写下了一些调试代码开始试验。结果你能想到，我疯了。一个开源库有3个文件，一个config，一个基础类加工具函数，***一个就是将近14W行代码大小2MB多的php文件，几乎所有的类都写在一个文件里面了。其实这也还好，不就是看代码会费事点么。重点是这个：

请注意这个库是没有命名空间的，类名也没有任何的前缀。敢问猴儿们做的项目里，有多少个项目是没有个Customer类？引入外部库是为了改自家的类名么？当然了，如果你的项目里本身就引入了命名空间，这个问题影响不大；但是大家手头在维护的项目里，大多都有超过几年的历史代码，也就是有很大几率是没有命名空间的。

后来作者为了解决这个命名冲突问题找到了一个乐于奉献的程序员，他帮忙把这个API整理成了命名空间+composer安装的方式(https://github.com/ryanwinchester/netsuite-php)。缺点就是没有实现Token Based Authentication，也没关系，继承一下加进去。哎，上回说到不要随便用private成员(http://zhuanlan./art/201606/513531.htm)，这会又碰到了，为了顺利继承，不得不把所有的private成员都拷一遍到自己写的继承类里。

作者理解猴儿的成长需要过程，需要不断试错方能练成九阴白骨爪。因为自己也是这么过来的，虽然白骨爪还没有，豉汁凤爪倒是有一对。但是像NetSuite这样的大品牌弄出这么青涩的库还真是很少见。

上面的描述略带夸张，开心呢您就笑一笑。话说回来，【差不多】先生和NetSuite都可以来看看关于代码组织方式这件事上，是不是凑合就可以了。这就要说到现今流行的几种方式了，PSR系列（PHP Standards Recomendations）。

PSR-0在2014年10月21日已经被标志为淘汰过时了，现在推荐的是PSR-4，我们看到composer里面还保留着对PSR-0的支持。

PSR-0，Autoloading Standard

文件的结构为Vendor\(Namespace)*\ClassName.php；每个命名空间的最顶层空间一定是Vendor，例如对于NetSuite来说，NetSuite就应该是它的最顶层命名空间；中间 可以有无数层命名空间；命名空间的分隔符会在找相应类文件时转换为系统的文件夹分隔符；类***的下划线 _ 对应着更深的文件夹层级，但是不影响命名空间；

PSR-4，Autoloader

这里的类指代class，interface、trait和类似的结构；命名空间与文件的对应结构跟PSR-0是一样的，除了在这个标准里下划线没有特别的作用，并且命名空间和文件名是大小写敏感的；Autoloader的实现不可以抛出异常、错误，也不返回任何值。

命名空间主要就是解决命名冲突的问题。合理的运用命名空间，可以让你的项目可具有扩展性，可维护性。寥寥草草的实现，只会让后期的开发维护成本越来越高。甚至现在你都不需要自己实现Autoloader，运用强大的composer，和遵循相关的理念就能让你事半功倍。

PSR-1，Basic Coding Standard

这里说的是一些代码的普遍标准，它可以使得团队相互协作变得更为顺利。

只使用

规则里面没有规定变量怎么命名，团队可以根据自己需要制定。小小的规则，却可以让团队，开源项目以一种和谐的方式相互协作，减少因为多样性而导致的内耗是很有实际意义的。如果团队里有程序猿一定要坚持自己的风格，这个猴子的合作精神一定是有待提高的。事实上一个团队各顾各的，失败就是必然的了。

PSR-2，Coding Style Guide

这是对PSR-1补充和扩展。

代码使用4个空格来缩进，而不是tab键（可以在IDE里面设置tab键转换为4空格）；一行的长度推荐80~120字符之间；namespace声明块后面要有一行空白，use声明块后面也要有一行空白；类和函数的花括号都独占一行；所有的类成员和函数都要显示声明可见性（不要省略掉public）；控制结构的关键字后面留一个空格，函数调用后面不要留空（if (x), test()）；控制结构的起始花括号与代码同行，结束花括号新起一行；控制结构的括号不要留空，例如if (x)。

当然还有其他的一些推荐标准，大家可以自行参考http://www.php-fig.org/psr/

说了这么多所谓的标准，目的无非就是为了更好的协作。有人说，我自己一个人做的项目我做主就好了。也没错，不过养成这些习惯也没有伤害，你咋知道你一不小心就做出了点啥可以拿出手的东西，不要等到那个时候再来整理代码来交代吧？

所以说，好的代码组织方式，真的不只是为了好看而已。

文章标题：好的代码组织方式只是为了更好看吗？
当前网址：http://www.shufengxianlan.com/qtweb/news32/426582.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联