- 1、本文档共15页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
PHP编程标准
PHP 编程标准(一)
标准化的重要性 标准化问题在某些方面上让每个人头痛, 让人人都觉得大家处于同样的境地. 这有助于让这些建议在许多的项目中不断演进, 许多公司花费了许多星期逐子字逐句的进行争论. 标准化不是特殊的个人风格, ...
标准化的重要性
标准化问题在某些方面上让每个人头痛, 让人人都觉得大家处于同样的境地. 这有助于让这些建
议在许多的项目中不断演进, 许多公司花费了许多星期逐子字逐句的进行争论. 标准化不是特殊
的个人风格, 它对本地改良是完全开放的.
优点
当一个项目尝试着遵守公用的标准时, 会有以下好处:
程序员可以了解任何代码, 弄清程序的状况
新人可以很快的适应环境
防止新接触php的人出于节省时间的需要, 自创一套风格并养成终生的习惯
防止新接触php的人一次次的犯同样的错误
在一致的环境下, 人们可以减少犯错的机会
程序员们有了一致的敌人 :-)
缺点
现在轮到坏处了:
因为标准由一些不懂得php的人所制定, 所以标准通常看上去很傻
因为标准跟我做的不一样, 所以标准通常看上去很傻
标准降低了创造力
标准在长期互相合作的人群中是没有必要的
标准强迫太多的格式
总之人们忽视标准
讨论
许多项目的经验能得出这样的结论:采用编程标准可以使项目更加顺利地完成. 标准是成功的关
键么?当然不. 但它们可以帮助我们, 而且我们需要我们能得到的所有的帮助!老实说, 对一个
细节标准的大部分争论主要是源自自负思想. 对一个合理的标准的很少决定能被说为是缺乏技术
性的话, 那只是口味的原因罢了. 所以, 要灵活的控制自负思想, 记住, 任何项目都取决于团队
合作的努力.
解释
惯例
在本文档中使用“要”字所指的是使用本规范的所有项目需要遵守规定的标准.
使用“应该”一词的作用是指导项目定制项目细节规范. 因为项目必须适当的包括 (include),
排除(exclude)或定制(tailor)需求.
使用“可以”一词的作用与“应该”类似, 因为它指明了可选的需求.
标准实施
首先应该在开发小组的内部找出所有的最重要的元素, 也许标准对你的状况还不够恰当. 它可能已经概
括了 重要的问题, 也可能还有人对其中的某些问题表示强烈的反对.
无论在什么情况下, 只要最后顺利的话, 人们将成熟的明白到这个标准是合理的, 然后其他的程序员们
也会发现它的合理性, 并觉得带着一些保留去遵循这一标准是值得的.
如果没有自愿的合作, 可以制定需求:标准一定要经过代码的检验.
如果没有检验的话, 这个解决方案仅仅是一个建立在不精确的基础上的一大群可笑的人.
认同观点
这行不通;
也许可行吧, 但是它既不实用又无聊;
这是真的, 而且我也告诉过你啊;
这个是我先想到的;
本来就应该这样.
如果您带着否定的成见而来看待事物的话, 请您保持开放的思想. 你仍可以做出它是废话的结论, 但是做
出结论的方法就是你必须要能够接受不同的思想. 请您给自己一点时间去做到它.
项目的四个阶段
数据库结构
设计
数据层
HTML层
--------------------------------------------------------------------------------
命名规则
合适的命名
命名是程序规划的核心. 古人相信只要知道一个人真正的名字就会获得凌驾于那个人之上的不可思议的力
量. 只要你给事物想到正确的名字, 就会给你以及后来的人带来比代码更强的力量. 别笑!
名字就是事物在它所处的生态环境中一个长久而深远的结果. 总的来说, 只有了解系统的程序员才能为系
统取出最合适的名字. 如果所有的命名都与其自然相适合, 则关系清晰, 含义可以推导得出, 一般人的推
想也能在意料之中.
如果你发觉你的命名只有少量能和其对应事物相匹配的话, 最好还是重新好好再看看你的设计吧.
类命名
在为类(class )命名前首先要知道它是什么. 如果通过类名的提供的线索, 你还是想不起这个类是
什么 的话, 那么你的设计就还做的不够好.
超过三个词组成的混合名是容易造成系统各个实体间的混淆, 再看看你的设计, 尝试使用(CRC Se-
ssion card)看看该命名所对应的实体是否有着那么多的功用.
对于派生类的命名应该避免带其父类名的诱惑, 一个类的名字只与它自身有关, 和它的父类叫什么无
关.
有时后缀名是有用的, 例如:如果你的系统使用了代理(agent ), 那么就把某个部件命名为“下
载代理”(DownloadAgent)用以真正的传送信息.
方法和函数命名
通常每个方法和函数都是执行一个动作的, 所以对它们的命名应该清楚的说明它们是做
文档评论(0)