php怎么看循环标签，什么样的代码叫好代码？
送大家以下java学习资料
简介： 我们每天都与代码打交道，但当被问道什么是好的代码时，很多人可能会先愣一下，然后给出的回答要么比较空泛，要么比较散，没办法简单明了地概括出来。显然，这个问题并没有唯一的标准答案，谁都可以谈论自己的理解，今天谈谈我对于好代码的理解。
我们每天都与代码打交道，但当被问道什么是好的代码时，很多人可能会先愣一下，然后给出的回答要么比较空泛，要么比较散，没办法简单明了地概括出来。显然，这个问题并没有唯一的标准答案，谁都可以谈论自己的理解，今天谈谈我对于好代码的理解。
一句话概括衡量代码质量的唯一有效标准：WTF/min —— Robert C. Martin
Bob大叔对于好代码的理解非常有趣，对我也有很大的启发。我们编写的代码，除了用于机器执行产生我们预期的效果以外，更多的时候是给人读的，这个读代码的可能是后来的维护人员，更多时候是一段时间后的作者本人。
我敢打赌每个人都遇到过这样的情况：过几周或者几个月之后，再看到自己写的代码，感觉一团糟，不禁怀疑人生。
我们自己写的代码，一段时间后自己看尚且如此，更别提拿给别人看了。
任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。—— Martin Fowler
所以，谈到好代码，首先跳入自己脑子里的一个词就是：整洁。
好的代码一定是整洁的，给阅读的人一种如沐春风，赏心悦目的感觉。
整洁的代码如同优美的散文。—— Grady Booch
好代码的特性很难给好的代码下一个定义，相信很多人跟我一样不会认为整洁的代码就一定是好代码，但好代码一定是整洁的，整洁是好代码的必要条件。整洁的代码一定是高内聚低耦合的，也一定是可读性强、易维护的。
高内聚低耦合
高内聚低耦合几乎是每个程序员员都会挂在嘴边的，但这个词太过于宽泛，太过于正确，所以聪明的编程人员们提出了若干面向对象设计原则来衡量代码的优劣：
开闭原则 OCP (The Open-Close Principle)单一职责原则 SRP (Single Responsibility Principle)依赖倒置原则 DIP (Dependence Inversion Principle)最少知识原则 LKP (Least Knowledge Principle)) / 迪米特法则 (Law Of Demeter)
里氏替换原则 LSP (Liskov Substitution Principle)接口隔离原则 ISP (Interface Segregation Principle)组合/聚合复用原则 CARP (Composite/Aggregate Reuse Principle)这些原则想必大家都很熟悉了，是我们编写代码时的指导方针，按照这些原则开发的代码具有高内聚低耦合的特性。换句话说，我们可以用这些原则来衡量代码的优劣。
但这些原则并不是死板的教条，我们也经常会因为其他的权衡（例如可读性、复杂度等）违背或者放弃一些原则。比如子类拥有特性的方法时，我们很可能打破里氏替换原则。再比如，单一职责原则跟接口隔离原则有时候是冲突的，我们通常会舍弃接口隔离原则，保持单一职责。只要打破原则的理由足够充分，也并不见得是坏的代码。
可读性
代码只要具有了高内聚和低耦合就足够好了吗？并不见得，我认为代码还必须是易读的。好的代码无论是风格、结构还是设计上都应该是可读性很强的。可以从以下几个方面考虑整洁代码，提高可读性。
命名
大到项目名、包名、类名，小到方法名、变量名、参数名，甚至是一个临时变量的名称，其命名都是很严肃的事，好的名字需要斟酌。
► 名副其实
好的名称一定是名副其实的，不需要注释解释即可明白其含义的。
/** * 创建后的天数 **/ int d; int daysSinceCreation;
后者比前者的命名要好很多，阅读者一下子就明白了变量的意思。
► 容易区分
我们很容易就会写下非常相近的方法名，仅从名称无法区分两者到底有啥区别（eg. getAccount()与getAccountInfo()），这样在调用时也很难抉择要用哪个，需要去看实现的代码才能确定。
► 可读的
名称一定是可读的，易读的，最好不要用自创的缩写，或者中英文混写。
► 足够短
名称当然不是越长越好，应该在足够表达其含义的情况下越短越好。
格式
良好的代码格式也是提高可读性非常重要的一环，分为垂直格式和水平格式。
► 垂直格式
通常一行只写一个表达式或者子句。一组代码代表一个完整的思路，不同组的代码中间用空行间隔。
public class Demo { @Resource private List<Handler> handlerList; private Map<TypeEnum, Handler> handlerMap = new ConcurrentHashMap<>(); @PostConstruct private void init() { if (!CollectionUtils.isEmpty(handlerList)) { for (Handler handler : handlerList) { handlerMap.put(handler.getType(), handler); } } } publicResult<Map<String, Object>> query(Long id, TypeEnum typeEnum) { Handler handler = handlerMap.get(typeEnum); if (null == handler) { return Result.returnFailed(ErrorCode.CAN_NOT_HANDLE); } return handler.query(id); } }
如果去掉了空行，可读性大大降低。
public class Demo { @Resource private List<Handler> handlerList; private Map<TypeEnum, Handler> handlerMap = new ConcurrentHashMap<>(); @PostConstruct private void init() { if (!CollectionUtils.isEmpty(handlerList)) { for (Handler handler : handlerList) { handlerMap.put(handler.getType(), handler); } } } public Result<Map<String, Object>> query(Long id, TypeEnum typeEnum) { Handler handler = handlerMap.get(typeEnum); if (null == handler) { return Result.returnFailed(ErrorCode.CAN_NOT_HANDLE); } return handler.query(id); } }
类静态变量、实体变量应定义在类的顶部。类内方法定义顺序依次是：公有方法或保护方法 > 私有方法 > getter/setter 方法。
► 水平格式
要有适当的缩进和空格。
► 团队统一
通常，同一个团队的风格尽量保持一致。集团对于 Java 开发进行了非常详细的规范。（可点击下方阅读原文，了解更多内容）
类与函数
► 类和函数应短小，更短小
类和函数都不应该过长（集团要求函数长度最多不能超过 80 行），过长的函数可读性一定差，往往也包含了大量重复的代码。
► 函数只做一件事（同一层次的事）
同一个函数的每条执行语句应该是统一层次的抽象。例如，我们经常会写一个函数需要给某个 DTO 赋值，然后再调用接口，接着返回结果。那么这个函数应该包含三步：DTO 赋值，调用接口，处理结果。如果函数中还包含了 DTO 赋值的具体操作，那么说明此函数的执行语句并不是在同一层次的抽象。
► 参数越少越好
参数越多的函数，调用时越麻烦。尽量保持参数数量足够少，最好是没有。
注释
► 别给糟糕的代码加注释，重构他
注释不能美化糟糕的代码。当企图使用注释前，先考虑是否可以通过调整结构，命名等操作，消除写注释的必要，往往这样做之后注释就多余了。
► 好的注释提供信息、表达意图、阐释、警告
我们经常遇到这样的情况：注释写的代码执行逻辑与实际代码的逻辑并不符合。大多数时候都是因为代码变化了，而注释并没有跟进变化。所以，注释最好提供一些代码没有的额外信息，展示自己的设计意图，而不是写具体如何实现。
► 删除掉注释的代码
git等版本控制已经帮我们记录了代码的变更历史，没必要继续留着过时的代码，注释的代码也会对阅读等造成干扰。
错误处理
► 错误处理很重要，但他不能搞乱代码逻辑
错误处理应该集中在同一层处理，并且错误处理的函数最好不包含其他的业务逻辑代码，只需要处理错误信息即可。
► 抛出异常时提供足够多的环境和说明，方便排查问题
异常抛出时最好将执行的类名，关键数据，环境信息等均抛出，此时自定义的异常类就派上用场了，通过统一的一层处理异常，可以方便快速地定位到问题。
► 特例模型可消除异常控制或者 null 判断
大多数的异常都是来源于NPE，有时候这个可以通过 Null Object 来消除掉。
► 尽量不要返回 null ，不要传 null 参数
不返回 null 和不传 null 也是为了尽量降低 NPE 的可能性。
如何判断不是好的代码讨论了好代码的必要条件，我们再来看看好代码的否定条件：什么不是好的代码。Kent Beck 使用味道来形容重构的时机，我认为当代码有坏味道的时候，也代表了其并不是好的代码。
代码的坏味道
► 重复
重复可能是软件中一切邪恶的根源。—— Robert C.Martin
Martin Fowler 也认为坏味道中首当其冲的就是重复代码。
很多时候，当我们消除了重复代码之后，发现代码就已经比原来整洁多了。
► 函数过长、类过大、参数过长
过长的函数解释能力、共享能力、选择能力都较差，也不易维护。
过大的类代表了类做了很多事情，也常常有过多的重复代码。
参数过长，不易理解，调用时也容易出错。
► 发散式变化、霰弹式修改、依恋情结
如果一个类不是单一职责的，则不同的变化可能都需要修改这个类，说明存在发散式变化，应考虑将不同的变化分离开。
如果某个变化需要修改多个类的方法，则说明存在霰弹式修改，应考虑将这些需要修改的方法放入同一个类。
如果函数对于某个类的兴趣高于了自己所处的类，说明存在依恋情结，应考虑将函数转移到他应有的类中。
► 数据泥团
有时候会发现三四个相同的字段，在多个类和函数中均出现，这时候说明有必要给这一组字段建立一个类，将其封装起来。
► 过多的 if...else 或者使用 switch
过多的 if...else 或者 switch ，都应该考虑用多态来替换掉。甚至有些人认为除个别情况外，代码中就不应该存在 if...else 。
总结本文首先一句话概括了我认为的好代码的必要条件：整洁，接着具体分析了整洁代码的特点，又分析了好代码的否定条件：什么样的代码不是好的代码。仅是本人的一些见解，希望对各位以后的编程有些许的帮助。
我认为仅仅编写出可运行的代码是远远不够的，还要时刻注意代码的整洁度，留下一些漂亮的代码，希望写的代码都能保留并运行 102 年！
后续增加一些实际的例子来说明好的和坏的代码；分享下如何编写整洁代码——自己认为有用的一些编程技巧。
在PHP中用dowhile求1到100的奇数和？
用dowhile做循环体是最基本的应用，这个题目的考察点应该就是在“奇数”上面，那么只要注意用于控制循环次数的变量，每次不是加1，而是加2，就解决了。
<?php $i=1;
$sum=0;
do{ $sum+=$i; $i=$i+2; }
while ($i<=100);
echo $sum; ?>
0基础学习编程？
本文从以下几个方面给大家分享几本高价值书单，并不一定全面，欢迎读者补充，希望能对你有帮助。
1 关于编码与重构
1.1 代码整洁之道
英文名《Clean code》，该书出自 Robert C Martin 之手，又被称为 Bob 大叔，是一位美国著名的软件工程师和作家，他已经写了有关敏捷软件开发的书籍。书中提到众多有名的编程原则：比如 SOLID 原则、 Law of Demeter（LoD，又被称为最少知识原则）。推荐理由：每个程序员都必须拥有本书并阅读它。这是一本非常著名的书，它将完全改变您的编程风格，书中介绍的规则均来自作者多年的实践经验，涵盖从命名、数据结构、面向对象的设计原理到重构的多个编程方面，虽为一“家”之言，然诚有可资借鉴的价值。或许，真正整洁的代码真能让同行读起来像诗一样。任何傻瓜都可以编写计算机可以理解的代码。优秀的程序员编写人类可以理解的代码。— 马丁·福勒如果只能读一本书，我就推荐这本。最后，基于本书，众多开发者还推出了各种语言的整洁之道：• Javascript 整洁之道• PHP 整洁之道• ABAP 整洁之道• Java 整洁之道• .NET 整洁之道还有各大科技公司的代码风格指南：• Google 风格指南• Uber Go 语言风格指南Bob 大叔的《架构整洁之道》也值得推荐，这本书是在架构领域的登峰之作，围绕“架构整洁”这一重要导向，系统地剖析其缘起、内涵及应用场景，涵盖软件研发完整过程及所有核心架构模式。还有《程序员的职业素养》，作者以自己以及身边的同事走过的弯路、犯过的错误为例，意在为后来人引路，助其职业生涯迈上更高台阶。1.2 重构（第2版）
英文名： 《Refactoring: Improving the Design of Existing Code，2nd Edition》，作者 Joshua Kerievsky。本书是理论和实践最佳组合的罕见书籍之一。重构是一个使您的工作代码更加美丽的过程，这本书可以利用已经尝试和测试的软件开发世界的模式来为您提供帮助。推荐理由：重构一词经常在各种大会上被提及，那就是这本书带来的影响。重构也就是重写软件的过程，而无需更改其功能，以提高其可读性，可检验性或可维护性。重构是使工作代码美观的过程，重构有助于改进工作代码的设计。这也是优秀程序员的必备技巧之一，通常优秀的程序员也擅长重构。本书将教你重构代码的艺术和科学。无论您是 Java 程序员、C++ 开发人员还是 Python 开发人员，每个程序员都可以从本书中受益。与《重构》经常被提及的书就是大名鼎鼎的《代码大全》，书中解释的也是久经考验的技术和策略，能有效帮助程序员和软件开发人员。笔者也曾在大学的时候把这本书图书馆借出来，发现这本书太厚，啃不动，到期就立马归还了。1.3 代码之美
英文名：《Beautiful Code: Leading Programmers Explain How They Think》，作者：Grey Wilson。推荐理由：大牛前辈的博客合集，同时也是提高编码技能的好书之一，因为它为您提供了一个机会，让您了解专业程序员如何处理问题、编写的代码以及他们如何解决问题，并且仍然能够保持他们的代码美观。这本书是一系列案例研究的集合，揭示了 Emacs 到 Facebook 等大型网站架构秘密，讲述了那些专家程序员，包括布莱恩·克尼原，乔恩·本特利（Jon Bentley）（编程珠玑的作者），蒂姆·布雷（Tim Bray），卡尔·福格尔（Karl Fogel），迈克尔·菲瑟斯（Michael Feathers）（有效地使用旧版代码的作者），以及许多更多伟大的作者和程序员。关于二分查找，在书中数次被不同作者提及，了解不同作者的观点。无论您使用哪种编码语言，例如 Java，C＃，Python 或 Ruby，都会在本书中找到有趣的东西。代码之美调查了一项努力的人类发明和创造力的范围：计算机系统的开发。每章中的美观来自发现独特的解决方案，这是作者的力量超越界限，识别他人所忽略的需求，并找到令人惊讶的解决方案，以解决令人困扰的问题。2 关于职业成长
2.1 程序员修炼之道（第2版）
英文名《Pragmatic programmer》，作者是 Andrew Hunt & David Thomas。中文版的译者是大名鼎鼎的云风，副标题是：通向务实的最高境界。推荐理由：本书是时隔 20 年的新版，覆盖哲学、方法、工具、设计、解耦、并发、重构、需求、团队等务实话题的最佳实践及重大陷阱，以及易于改造、复用的架构技术。刚出来的时候博文出版社举办了一个推广活动，在云风和皓子叔联袂推荐下，毫不犹豫的入手了本书。程序员往往最难得就是务实主义，总想追求新技术，炒新概念。工作后才逐渐明白，编程的本质，均不依赖于特定语言、框架和方法，技术改变世界在于能够有效解决用户的真实需求。本书本质上是程序员的自助指南。它探索了良好的软件开发实践，并为您提供了出色的建议、提示和技巧，以更有效地编程。正是对经典和现代轶事、引人入胜的类比和发人深省的例子的创造性使用，使每个部分的学习都变得有趣而有趣。如果说大学期间读的都是类似于 C 语言圣经和 Head First 系统书籍的话，工作后的人才会真正懂得为什么这本书籍不厚，读起来拍案叫好，这大概就是大道至简。作者另一著作：《程序员修炼之道: 从小工到专家》也是值得推荐的2.2 卓有成效的程序员
英文名：《The Productive Programmer》，作者：Neal Ford。推荐理由：本书就是讲述如何在开发软件的过程中变得更加高效。同时，《卓有成效的程序员》的讲述将会跨语言和操作系统：很多技巧的讲述都会伴随多种程序语言的例子，并且会跨越三种主要的操作系统，Windows（多个版本），Mac OS X 以及 *-nix (Unix 或者 Linux)。贯穿全文的思想大概就是尽量让机器做机器该做的事情，让程序和程序打交道，发挥程序员在这方面的先天优势。学会善用工具，命令行、学会写脚本，学会宏。提供效率，不去做重复单调的工作。最终的目的：成为一个“慵懒”的程序员。2.3 软技能：代码之外的生存指南
英文名：《Soft Skills: The software developer's life manual》，作者：John Z. Sonmez推荐理由：研究生期间读过最受益的一本非技术书。程序员都知道编码很重要，这是我们吃饭的硬技能。可是实际工作上才发现不止写代码，代码之外的软技能也很重要：比如面临着与客户沟通、与产品打交道的沟通问题；比如应该关注自身发展，书中也介绍了怎么做职业突围；还有更多章节介绍了作者如何学习、如何理财、健身、自我营销等等。分享书中有趣让我印象深刻的点是作者去面试，面试官浏览过他的博客文章，两人因此相谈甚欢。 最后也想给阅读的朋友声明一下：这本书涉猎了很多方面，但是并不是没一点都是一套可以照抄的完美答案，毕竟作者也是从当时的环境和自己经历出发介绍这些内容，每个读者应该都有自己的选择，综合而言，这本书挺适合各个阶段的人阅读的，尤其大学生和初入职场的朋友。作者也出了《软技能2：软件开发者职业生涯指南》，如果说软技能关注于生活，那软技能 2 则更加关注于了软件开发职业。3 关于黑客与开源
3.1 Unix 编程艺术
书籍英文名：《The Art of UNIX Programming》，作者：《Eric S. Raymond》从 1982 年开始就是 UNIX 开发者。推荐理由：本书涉及 Unix 系统领域中的设计和开发哲学、思想文化体系、原则与经验，由公认的 Unix 编程大师、开源运动领袖人物之一 Eric S.Raymond 倾力多年写作而成。程序会过时，编程语言会更新，代码会跟随业务不断改动，但编程思想的生命力会长盛不衰，好的编程艺术也是具有穿透力的，尽管书中的案例已经偏老，但贯穿始终的 KISS 原则、思想文化体系、设计与开发哲学一定能够给你带来醍醐灌顶的感觉。Keep it simple stupid，简称 KISS 原则。在做软件设计的工作中，很多时候都不要想得过于复杂，也不要过度设计和过早优化，用最简单且行之有效的方案也就避免了复杂方案带来的各种额外成本。这样既有利与后续的维护，也有利于进一步的扩展。另外，本书还可以与“左耳朵耗子”ef="">皓子叔推荐 过的《UNIX传奇：历史与回忆》结合着一起看，了解 UNIX 的诞生记与发展史，贝尔实验室的幕后故事！本书不但书写 Unix 的历史，而且记录作者的回忆，一探 Unix 的起源，试图解释什么是 Unix，Unix 是如何产生的，以及 Unix 为何如此重要。3.2 大教堂与集市
英文名：《The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary》， 《Unix编程艺术》作者 Eric S. Raymond 的另一封神之作，副标题是《对 Linux 和开源革命的沉思》。推荐理由：大家都知道程序员热衷于开源文化，都在说不要重复造轮子。开源时代下的软件开发可能只需要三个键盘按钮：CTRL + C + V，开个玩笑。说到开源文化，那么本书《大教堂与集市》是开源运动的《圣经》，颠覆了传统的软件开发思路，影响了整个软件开发领域。作者把软件开发思路类比于古代的大教堂文化和集市文化，讲述了集市如何变成大教堂，书中系统解释了开源软件是如何生产的，开源开发的优势在哪，开源软件的传承是如何做到的。3.3 黑客与画家
英文名：《Hackers and Painters: Big Ideas from the Computer Age》，作者：Paul Graham，本书的译者是大名鼎鼎的阮一峰大佬。推荐理由：说到黑客文化，就不得不提到硅谷创业之父Paul Graham 的这本书，本书主要介绍黑客 Hacker，即优秀程序员的爱好和动机，讨论黑客成长、黑客对世界的贡献以及编程语言和黑客工作方法等所有对计算机时代感兴趣的人的一些话题。本书是一本为黑客正名的技术散文集，看完书后第一次将我从电影中的黑客形象颠覆过来，才了解到并不是入侵系统、制作病毒、各种解密的人就是黑客，Hacker 是专家级程序员，是一群与画家有着极大的相似性，他们都是在创造，而不是完成某个任务，“黑客”象征着第一流的能力，以及求解问题过程中产生的精神愉悦或享受。他们崇尚分享、开放、民主、计算机的自由使用和进步。而那些恶意入侵计算机系统的人更应该被称为 cracker（骇客）。4 关于算法与设计模式
4.1 算法设计手册
英文名：The Algorithm Design Manual (2nd Ed.)，作者：Steven S Skiena推荐理由：关于算法的重要性大家都知道，大家肯定都知道另外两本著名的《算法导论》和《算法4》：《算法导论》侧重与算法的数学推导，适合研究，而《算法4》侧重于算法的代码实现，适合入门。而这次推荐的《算法设计手册(第2版)》却没有那么有名气，但也不失为设计实用且高效算法的最全面指导书。该书揭密了算法的设计与分析，以简单易懂的写作风格，介绍了各种算法技术，着重强调了算法分析。目前市场上算法书层出不穷，但是经典的算法却一直在那里，不曾走远。4.2 Head First 设计模式
英文名：《Head first design patterns》，作者：Elisabeth Freeman / / Eric Freeman / Bert Bates / Kathy Sierra / Elisabeth Robson推荐理由：这本书完整地涵盖了 GoF 版本全部23个设计模式，毫不费力地解释了世界各地熟练的软件开发人员和程序员用来构建优雅、功能齐全、灵活和可重用的软件的几种软件设计模式。。图文并茂，配有大量说明性和启发性的示例，它们将使学习同时变得高效和有趣。与其他文本繁重的编程书籍不同，这本书具有引人深思、视觉丰富的格式。Head First 系统书籍充满了幽默感，选题和编辑都很用心，值得一读。相信读完的读者逐步迈向对软件设计模式的深入了解。再来读 GoF 不失为一个不错的选择。4.3 设计模式：可复用面向对象软件的基础
英文名：《 Design Patterns: Elements of Reusable Object-Oriented Software》，又被简称为计算机领域的 GoF ，因为本书的作者是四个人：Erich Gamma / Richard Helm / Ralph Johnson / John Vlissides。推荐理由：本书是任何使用面向对象代码的开发人员的必备入门读物。而且作者 Erich Gamma 是 jUnit、Eclipse、IBM Jazz 项目、Visual Studio、Azure 和 Office 365 的幕后推手。如果您没有很好地掌握 UML，您可能会发现很难吸收编程书中汇编的一些信息和示例。然而，这不会阻止您欣赏设计模式书中叙述的美妙之处，它既简单又内容丰富。《设计模式》一书详尽地解释了 23 种软件设计模式，可帮助软件开发人员和设计人员制作更好、更优雅、更灵活的软件。这本书讨论了针对常见软件设计问题的大量简洁明了的解决方案。如果说 GoF 太难读下去，那么就推荐程杰的《大话设计模式》，这本书通过对话的形式带领大家入门设计模式，人人都可以是好学的小菜和经验丰富的大鸟。4.4 编程珠玑（第2版•修订版）
英文名：《More Programming Pearls，Second Edition》，作者：John Bentley推荐理由：这是一本带你真正领略计算机科学之美，融深邃思想、实战技术与趣味轶事于一炉的奇书。与大多数其他编程书籍不同，这本书侧重于基本问题和一般问题。它讨论了可以提高性能或减少内存需求的各种算法和技术。作者选取许多具有典型意义的复杂编程和算法问题，生动描绘了历史上众大师们在探索解决方案中发生的轶事、走过的弯路和不断精益求精的历程。就如书名一样，大浪淘沙，计算机科学中的智慧正如自然界里珍珠出自细沙对牡蛎的磨砺，留下一个个编程“珠肌”。题外话：
上面的书都是本人曾经阅读过，或者说在图书馆中有借阅翻过的书。也是计算机领域评分很高、有口皆碑的书籍。但计算机行业的经典书籍太多，本人能推荐的也只是其中一部分，想要推荐的内容也不想针对某个特定编程语言和领域，所以像《C++编程思想》和《On Java8》这类书籍没有进行推荐，推荐理由也不一定完全正确，欢迎大家批评指正。另外，看完上述的书并不能说自己就能在工作中就能运用到，看完就能成为一个顶尖的程序员。何况看书也不能完全接收前辈们的这些大智慧，但如果在某个瞬间（看书过程或者实践过程中）对自己有一种醍醐灌顶的感觉，就已足够。参考链接：
• UNIX传奇(上篇)• 假期好读书• Top 5 Books to Improve Coding and Programming Skills• http://www.osnews.com/images/comics/wtfm.jpg本文分享自华为云社区《【云驻共创】对于编程思想和能力有重大提升的书有哪些》，作者：宇宙之一粟 。
PHP的前身是？
PHP开发语言的前世今生
1994 年由Rasmus Lerdorf创建，刚刚开始只是一个简单的用Perl语言编写的程序，用来统计他自己网站的访问者。后来又用C语言重新编写，包括可以访问数据库。
在 1995年以Personal Home Page Tools (PHP Tools) 开始对外发表第一个版本，Lerdorf写了一些介绍此程序的文档，并且发布了PHP1.0。在这早期的版本中，提供了访客留言本、访客计数器等简单的功 能。以后越来越多的网站设计使用了PHP，并且强烈要求增加一些特性，比如循环语句和数组变量等 等，在新的成员加入开发行列之后，在1995年中，PHP2.0发布了。
第二版定名为PHP/FI(Form Interpreter)。PHP/FI加入了对mySQL的支持，从此建立了PHP在动态网页开发上的地位。到了1996年底，有15000个网站使用 PHP/FI；1997年中，使用PHP/FI的网站数字超过五万个。而在1997年中，开始了第三版的开发计划，开发小组加入了 Zeev Suraski 及 Andi Gutmans，而第三版就定名为PHP3。2000年，PHP4.0又问世了，其中增加了许多新的特性。
include和require的区别？
相同点：include和require都能把另外一个文件包含到当前文件中。
不同点：使用include时，当包含的文件不存在时，系统会报出警告级别的错误，程序会继续往下执行。
使用require包含文件时，当包含的文件不存在时，系统会先报出警告级别的错误，接着又报一个致命级别的错误。程序将终止执行。
require能让php的程序得到更高的效率，在同一php文件中解释过一次后，不会再解释第二次。而include却会重复的解释包含的文件。
所以当php网页中使用循环或条件语句引入文件时，"require"则不会做任何的改变，当出现这种情况，必须使用"include"命令来引入文件。