有没有办法让win 下也区分大小写？ 可以全部转成大写，或小写呀strtolower: 字串全转为小写。 strtoupper: 字串全转为大写。 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 本人研究linux还不深,但我认为不可能. 不知道win下怎么让他区分大小写，不过俺写的东西全是用小写文件名。 应该有个统一的规范吧，Win下面好像没有什么方法，只能从规范入手了 ：） 嗯。俺php文件的文件名全是小写，防止到linux下出问题。变量名，函数名什么的按下面的文章做的：）PHP编码规范1. 介绍 1.1. 标准化的重要** 标准化问题在某些方面上让每个人头痛，让人人都觉得大家处于同样的境地。这有助于让这些建议在许多的项目中不断演进，许多公司花费了许多星期逐子字逐句的进行争论。标准化不是特殊的个人风格，它对本地改良是完全开放的。 1.2. 优点 当一个项目尝试着遵守公用的标准时，会有以下好处： · 程序员可以了解任何代码，弄清程序的状况 · 新人可以很快的适应环境 · 防止新接触php的人出于节省时间的需要，自创一套风格并养成终生的习惯 · 防止新接触php的人一次次的犯同样的错误 · 在一致的环境下，人们可以减少犯错的机会 · 程序员们有了一致的敌人 1.3. 缺点 · 因为标准由一些不懂得php的人所制定，所以标准通常看上去很傻 · 因为标准跟我做的不一样，所以标准通常看上去很傻 · 标准降低了创造力 · 标准在长期互相合作的人群中是没有必要的 · 标准强迫太多的格式 1.4. 讨论 许多项目的经验能得出这样的结论：采用编程标准可以使项目更加顺利地完成。标准是成功的关键么？当然不。但它们可以帮助我们，而且我们需要我们能得到的所有的帮助！老实说，对一个细节标准的大部分争论主要是源自自负思想。对一个合理的标准的很少决定能被说为是缺乏技术**的话，那只是口味的原因罢了。所以，要灵活的控制自负思想，记住，任何项目都取决于团队合作的努力。 1.5. 解释 1.5.1. 标准实施 首先应该在开发小组的内部找出所有的最重要的元素，也许标准对你的状况还不够恰当。它可能已经概括了 重要的问题，也可能还有人对其中的某些问题表示强烈的反对。无论在什么情况下，只要最后顺利的话，人们将成熟的明白到这个标准是合理的，然后其他的程序员们也会发现它的合理**，并觉得带着一些保留去遵循这一标准是值得的。如果没有自愿的合作，可以制定需求：标准一定要经过代码的检验。如果没有检验的话，这个解决方案仅仅是一个建立在不精确的基础上的一大群可笑的人。 1.5.2. 认同观点 1. 这行不通； 2. 也许可行吧，但是它既不实用又无聊； 3. 这是真的，而且我也告诉过你啊； 4. 这个是我先想到的； 5. 本来就应该这样。 如果您带着否定的成见而来看待事物的话，请您保持开放的思想。你仍可以做出它是废话的结论，但是做出结论的方法就是你必须要能够接受不同的思想。请您给自己一点时间去做到它。 1.5.3. 项目的四个阶段 1. 数据库结构 2. 设计 3. 数据层 4. HTML层 2. 命名规则 2.1. 合适的命名命名是程序规划的核心。古人相信只要知道一个人真正的名字就会获得凌驾于那个人之上的不可思议的力量。只要你给事物想到正确的名字，就会给你以及后来的人带来比代码更强的力量。别笑！ 名字就是事物在它所处的生态环境中一个长久而深远的结果。总的来说，只有了解系统的程序员才能为系统取出最合适的名字。如果所有的命名都与其自然相适合，则关系清晰，含义可以推导得出，一般人的推想也能在意料之中。 如果你发觉你的命名只有少量能和其对应事物相匹配的话， 最好还是重新好好再看看你的设计吧。 2.2. 类命名 · 在为类（class ）命名前首先要知道它是什么。如果通过类名的提供的线索，你还是想不起这个类是什么的话，那么你的设计就还做的不够好。 · 超过三个词组成的混合名是容易造成系统各个实体间的混淆，再看看你的设计，尝试使用（CRC Session card)看看该命名所对应的实体是否有着那么多的功用。 · 对于派生类的命名应该避免带其父类名的诱惑，一个类的名字只与它自身有关，和它的父类叫什么无关。 · 有时后缀名是有用的，例如：如果你的系统使用了代理（agent ），那么就把某个部件命名为“下载代理”（DownloadAgent）用以真正的传送信息。 2.3. 方法和函数命名 · 通常每个方法和函数都是执行一个动作的，所以对它们的命名应该清楚的说明它们是做什么的：用CheckForErrors()代替ErrorCheck()，用DumpDataToFile()代替DataFile()。这么做也可以使功能和数据成为更可区分的物体。 · 有时后缀名是有用的: o Max - 含义为某实体所能赋予的最大值。 o Cnt - 一个运行中的计数变量的当前值。 o Key - 键值。 例如：RetryMax 表示最多重试次数，RetryCnt 表示当前重试次数。 · 有时前缀名是有用的： o Is - 含义为问一个关于某样事物的问题。无论何时，当人们看到Is就会知道这是一个问题。 o Get - 含义为取得一个数值。 o Set - 含义为设定一个数值 例如：IsHitRetryLimit。 2.4. 缩写词不要全部使用大写字母 · 无论如何，当遇到以下情况，你可以用首字母大写其余字母小写来代替全部使用大写字母的方法来表示缩写词。 使用: GetHtmlStatistic. 不使用: GetHTMLStatistic. 理由 · 当命名含有缩略词时，人们似乎有着非常不同的直觉。统一规定是最好，这样一来，命名的含义就完全可以预知了。 举个NetworkABCKey的例子，注意C是应该是ABC里面的C还是key里面的C，这个是很令人费解的。有些人不在意这些，其他人却很讨厌这样。所以你会在不同的代码里看到不同的规则，使得你不知道怎么去叫它。 例如 class FluidOz // 不要写成 FluidOZ class GetHtmlStatistic // 不要写成 GetHTMLStatistic 2.5. 类命名 · 使用大写字母作为词的分隔，其他的字母均使用小写 · 名字的首字母使用大写 · 不要使用下划线(_) 理由 · 根据很多的命名方式，大部分人认为这样是最好的方式。 例如 class NameOneTwo class Name 2.6. 类库命名 · 目前命名空间正在越来越广泛的被采用，以避免不同厂商和团体类库间的类名冲突。 · 当尚未采用命名空间的时候，为了避免类名冲突，一般的做法是在类名前加上独特的前缀，两个字符就可以了，当然多用一些会更好。 例如 John Johnson的数据结构类库可以用Jj做为前缀，如下： class JjLinkList { } 另一种折中方式是建立包含类库目录（事实上Java也是这么做的），以不通的目录代表不同的命名空间。 例如 Microsoft的数据库相关类库可以在： /classes/com/Microsoft/ Database/DbConn.php Apache的数据库相关类库可在： /classes/org/apache/Database/DbConn.php 2.7. 方法命名 · 采用与类命名一致的规则 理由 · 使用所有不同规则的大部分人发现这是最好的折衷办法。 例如 class NameOneTwo { function DoIt() {}; function HandleError() {}; } 2.8. 类属**命名 · 属**命名应该以字符‘m’为前缀。 · 前缀‘m’后采用于类命名一致的规则。 · ‘m’总是在名字的开头起修饰作用，就像以‘r’开头表示引用一样。 理由 · 前缀m防止类属**和方法名发生任何冲突。你的方法名和属**名经常会很类似，特别是存取元素。 例如 class NameOneTwo { function VarAbc() {}; function ErrorNumber() {}; var $mVarAbc; var $mErrorNumber; var $mrName; } 2.9. 方法中参数命名 · 第一个字符使用小写字母。 · 在首字符后的所有字都按照类命名规则首字符大写。 理由 · 可以区分方法中的一般变量。 · 你可以使用与类名相似的名称而不至于产生重名冲突。 例如 class NameOneTwo { function StartYourEngines( &$rSomeEngine, &$rAnotherEngine); } 2.10. 变量命名 · 所有字母都使用小写 · 使用_作为每个词的分界。 理由 · 通过这一途径，代码中变量的作用域是清晰的。 · 所有的变量在代码中都看起来不同，容易辨认。 例如 function HandleError($errorNumber) { $error = OsErr($errorNumber); $time_of_error = OsErr->GetTimeOfError(); $error_processor = OsErr->GetErrorProcessor(); } 2.11. 引用变量和函数返回引用 · 引用必须带‘r’前缀 理由 · 使得类型不同的变量容易辨认 · 它可以确定哪个方法返回可更改对象，哪个方法返回不可更改对象。 例如 class Test { var mrStatus; function DoSomething(&$rStatus) {}; function &rStatus() {}; } 2.12. 全局变量 · 全局变量应该带前缀‘g’。 理由 · 知道一个变量的作用域是非常重要的。 例如 global $gLog; global &$grLog; 2.13. 定义命名 / 全局常量 · 全局常量用_分隔每个单词。 理由 这是命名全局常量的传统。你要注意不要与其它的定义相冲突。 例如 define("A_GLOBAL_CONSTANT", "Hello world!"); 2.14. 静态变量 · 静态变量应该带前缀‘s’。 理由 · 知道一个变量的作用域是非常重要的。 例如 function test() { static $msStatus = 0; } ?> 3.12. 不要采用缺省方法测试非零值 不要采用缺省值测试非零值，也就是使用： if (FAIL != f()) 比下面的方法好： if (f()) 即使 FAIL 可以含有 0 值 ，也就是php认为false的表示。在某人决定用-1代替0作为失败返回值的时候，一个显式的测试就可以帮助你了。就算是比较值不会变化也应该使用显式的比较；例如：if (!($bufsize % strlen($str)))应该写成：if (($bufsize % strlen($str)) == 0)以表示测试的数值（不是布尔）型。一个经常出问题的地方就是使用strcmp来测试一个字符等式，结果永远也不会等于缺省值。 非零测试采用基于缺省值的做法，那么其他函数或表达式就会受到以下的限制: · 只能返回0表示失败，不能为/有其他的值。 · 命名以便让一个真(true)的返回值是绝对显然的，调用函数IsValid()而不是Checkvalid()。 3.13. 布尔逻辑类型 大部分函数在FALSE的时候返回0，但是发挥非0值就代表TRUE，因而不要用1（TRUE，YES，诸如此类）等式检测一个布尔值，应该用0（FALSE，NO，诸如此类）的不等式来代替： if (TRUE == func()) { ... 应该写成： if (FALSE != func()) { ... 3.14. 通常避免嵌入式的赋值 有时候在某些地方我们可以看到嵌入式赋值的语句，那些结构不是一个比较好的少冗余，可读**强的方法。 while ($a != ($c = getchar())) { process the character } ++和--操作符类似于赋值语句。因此，出于许多的目的，在使用函数的时候会产生副作用。使用嵌入式赋值提高运行时**能是可能的。无论怎样，程序员在使用嵌入式赋值语句时需要考虑在增长的速度和减少的可维护**两者间加以权衡。例如： a = b + c; d = a + r; 不要写成： d = (a = b + c) + r; 虽然后者可以节省一个周期。但在长远来看，随着程序的维护费用渐渐增长，程序的编写者对代码渐渐遗忘，就会减少在成熟期的最优化所得。 4. 帮助与共享 4.1. 重用您和其他人的艰苦工作 跨工程的重用在没有一个通用结构的情况下几乎是不可能的。对象符合他们现有的服务需求，不同的过程有着不同的服务需求环境，这使对象重用变得很困难。 开发一个通用结构需要预先花费许多的努力来设计。当努力不成功的时候，无论出于什么原因，有几种办法推荐使用： 4.2. 请教！给群组发Email求助 这个简单的方法很少被使用。因为有些程序员们觉得如果他向其他人求助，会显得自己水平低，这多傻啊!做新的有趣的工作，不要一遍又一遍的做别人已经做过的东西。 如果你需要某些事项的源代码，如果已经有某人做过的话，就向群组发email求助。结果会很惊喜哦！ 在许多大的群组中，个人往往不知道其他人在干什么。你甚至可以发现某人在找一些东西做，并且自愿为你写代码，如果人们在一起工作，外面就总有一个金矿。 4.3. 告诉！当你在做事的时候，把它告诉所有人 如果你做了什么可重用的东西的话，让其他人知道。别害羞，也不要为了保护自豪感而把你的工作成果藏起来。一旦养成共享工作成果的习惯，每个人都会获得更多。 4.4. 小型代码库 对于代码重用，一个常见的问题就是人们不从他们做过的代码中做库。一个可重用的类可能正隐蔽在一个程序目录并且决不会有被分享的激动，因为程序员不会把类分拆出来加入库中。 这样的其中一个原因就是人们不喜欢做一个小库，对小库有一些不正确感觉。把这样的感觉克服掉吧，电脑才不关心你有多少个库呢。 如果你有一些代码可以重用，而且不能放入一个已经存在的库中，那么就做一个新的库吧。如果人们真的考虑重用的话，库不会在很长的一段时间里保持那么小的。 4.5. 知识库 很多公司不清楚现有什么代码可用，而且大多数程序员仍然没有通过沟通他们已经做过了什么，或者一直在询问现存什么代码可用。解决这个的方法是有一个可用的知识库。 理想的情况是，程序员可以到一个WEB页，浏览或者查询打包的知识库列表，找到他们所要的。建立一个程序员可以自动维护的知识库系统，是一个很不错的做法。如果有一个专门的管理员来负责维护这个知识库，那当然更好。 另一种方法是自动的从代码中产生知识库的做法。把通用的类、方法和标头（subsystem headers）作为手册或者是知识库的一个条目。 5. 书写注释 5.1. 讲一个故事 把你的注释当作描述系统的一个故事。并且使得你的注释能被机器解析后，以固定的格式放到手册中去。类的注释是故事的一部分，方法的名称、方法的注释、方法的实现也是故事一部分。所有的这些部分编织在一起，使得人们在以后的时间里能够准确的知道你干了什么，为什么这么做。 5.2. 归档注释 注释的要归档才有意义，否则，假如在一个地方放一条注释描述你做了什么选择和你为什么这么做，只有考古学家才能发现这是最有用的信息。（如何归档另行规范） 5.3. 注释结构 工程的每部分都有特定的注释结构。 程序中的注释，这里给出示例作为规范，注释中以 * @ 为关键字的开始，以:为注释关键字结尾。 5.3.1. 预定义关键字 关键字 含义 Purpose 表示类、属**、方法要做些什么或者什么含义。 Package Name 类名 Author 作者 Modifications 修改记录（编号规则为“No”＋日期＋“－”＋序号） See 参考 Method Name 方法名 Parameter 参数名（包括类型） Return 返回值（包括类型） Attribute/Variable Name 属**/变量名 Type 属**/变量类型 ?> 呵呵，还有一点没贴全，贴不出来了，，，全文还是用google搜一下：） 这是中国PHP联盟写的全文可以到www.phpx.com查询。 请问这个简单的查询还有没有优化的余地 能不能用php向服务器发送自己设定的User-Agent信息 在64位windows7上该装哪个php_imagick.dll？ Php 读取json_decode数据的问题 请问：怎么获取第二个多选框的全部值？ 关于php的目录保护问题，请高手指教，急 个关于文件存放方式的问题 大家帮我参考一下（进者有分） 不知道这么晚有没有人帮忙 阵列的问题 希望這里的文章能給大家帶來方便之處! 为什么mysql中选择的时候，不能部分匹配？ 小问题？为什么我设置的php4中的user_dir 无效呢？
不过俺写的东西全是用小写文件名。
变量名，函数名什么的按下面的文章做的：）PHP编码规范1. 介绍
1.1. 标准化的重要**
标准化问题在某些方面上让每个人头痛，让人人都觉得大家处于同样的境地。这有助于让这些建议在许多的项目中不断演进，许多公司花费了许多星期逐子字逐句的进行争论。标准化不是特殊的个人风格，它对本地改良是完全开放的。
1.2. 优点
当一个项目尝试着遵守公用的标准时，会有以下好处：
· 程序员可以了解任何代码，弄清程序的状况
· 新人可以很快的适应环境
· 防止新接触php的人出于节省时间的需要，自创一套风格并养成终生的习惯
· 防止新接触php的人一次次的犯同样的错误
· 在一致的环境下，人们可以减少犯错的机会
· 程序员们有了一致的敌人
1.3. 缺点
· 因为标准由一些不懂得php的人所制定，所以标准通常看上去很傻
· 因为标准跟我做的不一样，所以标准通常看上去很傻
· 标准降低了创造力
· 标准在长期互相合作的人群中是没有必要的
· 标准强迫太多的格式
1.4. 讨论
许多项目的经验能得出这样的结论：采用编程标准可以使项目更加顺利地完成。标准是成功的关键么？当然不。但它们可以帮助我们，而且我们需要我们能得到的所有的帮助！老实说，对一个细节标准的大部分争论主要是源自自负思想。对一个合理的标准的很少决定能被说为是缺乏技术**的话，那只是口味的原因罢了。所以，要灵活的控制自负思想，记住，任何项目都取决于团队合作的努力。
1.5. 解释
1.5.1. 标准实施
首先应该在开发小组的内部找出所有的最重要的元素，也许标准对你的状况还不够恰当。它可能已经概括了 重要的问题，也可能还有人对其中的某些问题表示强烈的反对。无论在什么情况下，只要最后顺利的话，人们将成熟的明白到这个标准是合理的，然后其他的程序员们也会发现它的合理**，并觉得带着一些保留去遵循这一标准是值得的。如果没有自愿的合作，可以制定需求：标准一定要经过代码的检验。如果没有检验的话，这个解决方案仅仅是一个建立在不精确的基础上的一大群可笑的人。
1.5.2. 认同观点
1. 这行不通；
2. 也许可行吧，但是它既不实用又无聊；
3. 这是真的，而且我也告诉过你啊；
4. 这个是我先想到的；
5. 本来就应该这样。
如果您带着否定的成见而来看待事物的话，请您保持开放的思想。你仍可以做出它是废话的结论，但是做出结论的方法就是你必须要能够接受不同的思想。请您给自己一点时间去做到它。
1.5.3. 项目的四个阶段
1. 数据库结构
2. 设计
3. 数据层
4. HTML层 2. 命名规则 2.1. 合适的命名命名是程序规划的核心。古人相信只要知道一个人真正的名字就会获得凌驾于那个人之上的不可思议的力量。只要你给事物想到正确的名字，就会给你以及后来的人带来比代码更强的力量。别笑！
名字就是事物在它所处的生态环境中一个长久而深远的结果。总的来说，只有了解系统的程序员才能为系统取出最合适的名字。如果所有的命名都与其自然相适合，则关系清晰，含义可以推导得出，一般人的推想也能在意料之中。
如果你发觉你的命名只有少量能和其对应事物相匹配的话， 最好还是重新好好再看看你的设计吧。 2.2. 类命名 · 在为类（class ）命名前首先要知道它是什么。如果通过类名的提供的线索，你还是想不起这个类是什么的话，那么你的设计就还做的不够好。
· 超过三个词组成的混合名是容易造成系统各个实体间的混淆，再看看你的设计，尝试使用（CRC Session card)看看该命名所对应的实体是否有着那么多的功用。
· 对于派生类的命名应该避免带其父类名的诱惑，一个类的名字只与它自身有关，和它的父类叫什么无关。
· 有时后缀名是有用的，例如：如果你的系统使用了代理（agent ），那么就把某个部件命名为“下载代理”（DownloadAgent）用以真正的传送信息。 2.3. 方法和函数命名 · 通常每个方法和函数都是执行一个动作的，所以对它们的命名应该清楚的说明它们是做什么的：用CheckForErrors()代替ErrorCheck()，用DumpDataToFile()代替DataFile()。这么做也可以使功能和数据成为更可区分的物体。
· 有时后缀名是有用的:
o Max - 含义为某实体所能赋予的最大值。
o Cnt - 一个运行中的计数变量的当前值。
o Key - 键值。
例如：RetryMax 表示最多重试次数，RetryCnt 表示当前重试次数。
· 有时前缀名是有用的：
o Is - 含义为问一个关于某样事物的问题。无论何时，当人们看到Is就会知道这是一个问题。
o Get - 含义为取得一个数值。
o Set - 含义为设定一个数值
例如：IsHitRetryLimit。 2.4. 缩写词不要全部使用大写字母 · 无论如何，当遇到以下情况，你可以用首字母大写其余字母小写来代替全部使用大写字母的方法来表示缩写词。
使用: GetHtmlStatistic.
不使用: GetHTMLStatistic.
理由
· 当命名含有缩略词时，人们似乎有着非常不同的直觉。统一规定是最好，这样一来，命名的含义就完全可以预知了。
举个NetworkABCKey的例子，注意C是应该是ABC里面的C还是key里面的C，这个是很令人费解的。有些人不在意这些，其他人却很讨厌这样。所以你会在不同的代码里看到不同的规则，使得你不知道怎么去叫它。
例如
class FluidOz // 不要写成 FluidOZ
class GetHtmlStatistic // 不要写成 GetHTMLStatistic 2.5. 类命名 · 使用大写字母作为词的分隔，其他的字母均使用小写
· 名字的首字母使用大写
· 不要使用下划线(_)
理由
· 根据很多的命名方式，大部分人认为这样是最好的方式。
例如
class NameOneTwo
class Name 2.6. 类库命名 · 目前命名空间正在越来越广泛的被采用，以避免不同厂商和团体类库间的类名冲突。
· 当尚未采用命名空间的时候，为了避免类名冲突，一般的做法是在类名前加上独特的前缀，两个字符就可以了，当然多用一些会更好。
例如
John Johnson的数据结构类库可以用Jj做为前缀，如下：
class JjLinkList
{
}
另一种折中方式是建立包含类库目录（事实上Java也是这么做的），以不通的目录代表不同的命名空间。
例如
Microsoft的数据库相关类库可以在：
/classes/com/Microsoft/ Database/DbConn.php
Apache的数据库相关类库可在：
/classes/org/apache/Database/DbConn.php 2.7. 方法命名 · 采用与类命名一致的规则
理由
· 使用所有不同规则的大部分人发现这是最好的折衷办法。
例如
class NameOneTwo
{
function DoIt() {};
function HandleError() {};
} 2.8. 类属**命名 · 属**命名应该以字符‘m’为前缀。
· 前缀‘m’后采用于类命名一致的规则。
· ‘m’总是在名字的开头起修饰作用，就像以‘r’开头表示引用一样。
理由
· 前缀m防止类属**和方法名发生任何冲突。你的方法名和属**名经常会很类似，特别是存取元素。
例如
class NameOneTwo
{
function VarAbc() {};
function ErrorNumber() {};
var $mVarAbc;
var $mErrorNumber;
var $mrName;
} 2.9. 方法中参数命名 · 第一个字符使用小写字母。
· 在首字符后的所有字都按照类命名规则首字符大写。
理由
· 可以区分方法中的一般变量。
· 你可以使用与类名相似的名称而不至于产生重名冲突。
例如
class NameOneTwo
{
function StartYourEngines(
&$rSomeEngine,
&$rAnotherEngine);
} 2.10. 变量命名 · 所有字母都使用小写
· 使用_作为每个词的分界。
理由
· 通过这一途径，代码中变量的作用域是清晰的。
· 所有的变量在代码中都看起来不同，容易辨认。
例如
function HandleError($errorNumber)
{
$error = OsErr($errorNumber);
$time_of_error = OsErr->GetTimeOfError();
$error_processor = OsErr->GetErrorProcessor();
} 2.11. 引用变量和函数返回引用 · 引用必须带‘r’前缀
理由
· 使得类型不同的变量容易辨认
· 它可以确定哪个方法返回可更改对象，哪个方法返回不可更改对象。
例如
class Test
{
var mrStatus;
function DoSomething(&$rStatus) {};
function &rStatus() {};
} 2.12. 全局变量 · 全局变量应该带前缀‘g’。
理由
· 知道一个变量的作用域是非常重要的。
例如
global $gLog;
global &$grLog; 2.13. 定义命名 / 全局常量 · 全局常量用_分隔每个单词。
理由
这是命名全局常量的传统。你要注意不要与其它的定义相冲突。
例如
define("A_GLOBAL_CONSTANT", "Hello world!"); 2.14. 静态变量 · 静态变量应该带前缀‘s’。
理由
· 知道一个变量的作用域是非常重要的。
例如
function test()
{
static $msStatus = 0;
} ?>
比下面的方法好： if (f()) 即使 FAIL 可以含有 0 值 ，也就是php认为false的表示。在某人决定用-1代替0作为失败返回值的时候，一个显式的测试就可以帮助你了。就算是比较值不会变化也应该使用显式的比较；例如：if (!($bufsize % strlen($str)))应该写成：if (($bufsize % strlen($str)) == 0)以表示测试的数值（不是布尔）型。一个经常出问题的地方就是使用strcmp来测试一个字符等式，结果永远也不会等于缺省值。
非零测试采用基于缺省值的做法，那么其他函数或表达式就会受到以下的限制:
· 只能返回0表示失败，不能为/有其他的值。
· 命名以便让一个真(true)的返回值是绝对显然的，调用函数IsValid()而不是Checkvalid()。 3.13. 布尔逻辑类型 大部分函数在FALSE的时候返回0，但是发挥非0值就代表TRUE，因而不要用1（TRUE，YES，诸如此类）等式检测一个布尔值，应该用0（FALSE，NO，诸如此类）的不等式来代替： if (TRUE == func()) { ...
应该写成： if (FALSE != func()) { ... 3.14. 通常避免嵌入式的赋值 有时候在某些地方我们可以看到嵌入式赋值的语句，那些结构不是一个比较好的少冗余，可读**强的方法。 while ($a != ($c = getchar()))
{
process the character
}
++和--操作符类似于赋值语句。因此，出于许多的目的，在使用函数的时候会产生副作用。使用嵌入式赋值提高运行时**能是可能的。无论怎样，程序员在使用嵌入式赋值语句时需要考虑在增长的速度和减少的可维护**两者间加以权衡。例如： a = b + c;
d = a + r;
不要写成： d = (a = b + c) + r; 虽然后者可以节省一个周期。但在长远来看，随着程序的维护费用渐渐增长，程序的编写者对代码渐渐遗忘，就会减少在成熟期的最优化所得。
4. 帮助与共享 4.1. 重用您和其他人的艰苦工作 跨工程的重用在没有一个通用结构的情况下几乎是不可能的。对象符合他们现有的服务需求，不同的过程有着不同的服务需求环境，这使对象重用变得很困难。
开发一个通用结构需要预先花费许多的努力来设计。当努力不成功的时候，无论出于什么原因，有几种办法推荐使用： 4.2. 请教！给群组发Email求助 这个简单的方法很少被使用。因为有些程序员们觉得如果他向其他人求助，会显得自己水平低，这多傻啊!做新的有趣的工作，不要一遍又一遍的做别人已经做过的东西。
如果你需要某些事项的源代码，如果已经有某人做过的话，就向群组发email求助。结果会很惊喜哦！
在许多大的群组中，个人往往不知道其他人在干什么。你甚至可以发现某人在找一些东西做，并且自愿为你写代码，如果人们在一起工作，外面就总有一个金矿。 4.3. 告诉！当你在做事的时候，把它告诉所有人 如果你做了什么可重用的东西的话，让其他人知道。别害羞，也不要为了保护自豪感而把你的工作成果藏起来。一旦养成共享工作成果的习惯，每个人都会获得更多。 4.4. 小型代码库 对于代码重用，一个常见的问题就是人们不从他们做过的代码中做库。一个可重用的类可能正隐蔽在一个程序目录并且决不会有被分享的激动，因为程序员不会把类分拆出来加入库中。
这样的其中一个原因就是人们不喜欢做一个小库，对小库有一些不正确感觉。把这样的感觉克服掉吧，电脑才不关心你有多少个库呢。
如果你有一些代码可以重用，而且不能放入一个已经存在的库中，那么就做一个新的库吧。如果人们真的考虑重用的话，库不会在很长的一段时间里保持那么小的。 4.5. 知识库 很多公司不清楚现有什么代码可用，而且大多数程序员仍然没有通过沟通他们已经做过了什么，或者一直在询问现存什么代码可用。解决这个的方法是有一个可用的知识库。
理想的情况是，程序员可以到一个WEB页，浏览或者查询打包的知识库列表，找到他们所要的。建立一个程序员可以自动维护的知识库系统，是一个很不错的做法。如果有一个专门的管理员来负责维护这个知识库，那当然更好。
另一种方法是自动的从代码中产生知识库的做法。把通用的类、方法和标头（subsystem headers）作为手册或者是知识库的一个条目。
5. 书写注释
5.1. 讲一个故事 把你的注释当作描述系统的一个故事。并且使得你的注释能被机器解析后，以固定的格式放到手册中去。类的注释是故事的一部分，方法的名称、方法的注释、方法的实现也是故事一部分。所有的这些部分编织在一起，使得人们在以后的时间里能够准确的知道你干了什么，为什么这么做。 5.2. 归档注释 注释的要归档才有意义，否则，假如在一个地方放一条注释描述你做了什么选择和你为什么这么做，只有考古学家才能发现这是最有用的信息。（如何归档另行规范） 5.3. 注释结构 工程的每部分都有特定的注释结构。 程序中的注释，这里给出示例作为规范，注释中以 * @ 为关键字的开始，以:为注释关键字结尾。 5.3.1. 预定义关键字 关键字 含义
Purpose 表示类、属**、方法要做些什么或者什么含义。
Package Name 类名
Author 作者
Modifications 修改记录（编号规则为“No”＋日期＋“－”＋序号）
See 参考
Method Name 方法名
Parameter 参数名（包括类型）
Return 返回值（包括类型）
Attribute/Variable Name 属**/变量名
Type 属**/变量类型 ?>
全文可以到www.phpx.com查询。