if 和 switch 语句效率比较

在 switch 语句中条件只求值一次并用来和每个 case 语句比较。在 elseif 语句中条件会再次求值。如果条件比一个简单的比较要复杂得多或者在一个很多次的循环中，那么用 switch 语句可能会快一些。

以上为 php 手册在叙述 switch 中的一句，该怎么理解呢？

从整体效率上看，是相当的。但区别存在于呢？举个例子

if ($noizy==1) {

   echo "noizy1";

} elseif ($noizy==2) {
  
   echo "noizy2";

} elseif ($noizy==3) {

   echo "noizy3";

}

以上是 if 代码的一个片段，在最差的状况下，也就是当 $noizy = 3 时，共运行了3次比较，而且，每次比较都必须取出 $noizy 的值一次。如果换成 switch

switch ($noizy) {
   case 1:
      echo "1";
      break;
   case 2:
      echo "2";
      break;
   case 3:
      echo "3";
      break;
}

只在开头 switch 的括号中取出 $noizy 的值，然后把值与case值逐一进行比较

效率的差别就在这儿，因此我总结几点：

1.当只进行一次比较时，推荐使用 if，原因很简单，此时 if 与 switch 没有本质区别，而用 if 代码较为简洁，省去多余字节，可乐而不为？
2.当多次纯粹的比较数字或字符时，推荐使用 switch，当进行N次比较，switch 只取值一次，而 if …… elseif 则取值 1 <= x <= N (x 为实际次数)。
3.当遇到复合条件时，应该视情况而灵活运用 if 与 switch。

Techniques to handle Complexity:Abstraction, Specification and Problem Decomposition

In Web application development process, there are lots of technologies is good to carry out. But Specification, Abstraction and Problem Decomposition is a perfect approach to resolve the Complexity of the software engineer. They are knowledge comes from practice.
So, remember them, and use them every day.

读林斌博士写好代码十个秘诀

软件的质量属性

鲁棒 - Solid and Robust Code
简洁 - Maintainable and Simple Code
高效 - Fast Code
简短 - Small Code
共享 - Re-usable Code
可测试 - Testable Code
可移植 - Portable Code

集百家之长, 归我所用 - Follow Basic Coding Style
1.代码能够清晰的表达你的思路
2.代码应该具备自解释能力，注释代码别是单纯解释语句，这种注释毫无意义
3.编码的缩进和排版规范
4.所有的函数和变量应有他人容易理解的名字
5.将Tab键改用为4个空格字符
6.减少单个函数的长度，控制在50-100行以内
7.避免幻数，多使用枚举和常量的定义

取个好名字 - Use Naming Conventions
1.采用匈牙利命名法对变量进行命名
2.名字要清晰表达含义，不要怕长

凌波微步, 未必摔跤 - Evil goto’s? Maybe Not…
1.goto的使用应该遵循原则，而不是全盘否定
2.不用写高深晦涩的语句，不要一味追求性能忽视代码可读性
3.模式并不是一味正确，特定问题更需要考虑反模式

先发制人, 后发制于人- Practice Defensive Coding
1.尽量保持代码的简洁和简单
2.调用其它接口和函数时候首先对返回值进行检查
3.避免有符号/无符号,32位/16位，被零除等误算情况

见招拆招, 滴水不漏 - Handle The Error Cases: They Will Occur!
1.通过异常处理机制来保证程序代码的健壮性
2.异常处理中一定要注意资源的释放
3.异常处理要关注日志的详细记录，便于后续BUG分析
4.不用把后台编码或系统异常直接抛给用户

熟习剑法刀术, 所向无敌 - Learn Win32 API Seriously
1.Win32 API是微软平台编程根本
2.对系统强大的公用类库的熟悉和整理将事半功倍

双手互搏, 无坚不摧 - Test, but don’t stop there
1.如果你没有进行测试，你完成的代码将仅仅是个半成品
2.尽可能多的对自己的代码进行测试
3.编码人员应该更专注于白盒测试和单元测试
4.要善于使用JUnit,NUnit，PureCoverage,Compuware,NCover等测试工具
5.相互间的Review和走查是对代码可维护性的重要测试手段
6.有特殊性能要求时候需要对相关功能或模块单独进行性能测试

活用断言 - Use, don’t abuse, assertions
1.断言可以很好的描述假设和不可能的情况
2.断言对程序Debug很有用，可以尽早的发现程序问题

草木皆兵, 不可大意 - Avoid Assumptions
1.考虑到用户使用的各种场景
2.不用假设用户会正确输入数据，要做好各种完整性和边界的检验
3.程序中70%左右代码是为了保证这种完整性服务的，正常条件下功能可能30%代码就实现了

最高境界, 无招胜有招 - Stop writing so much code
1.一味拷贝粘贴代码就是在制造拷贝BUG，这种代码对系统无任何意义
2.编码过程注意重用，函数级->组件级->系统级
3.通过重构持续改进代码质量，改进自我逻辑思维

最后总结下：
1.养成良好编码习惯，你面试的一小段代码可能就足以展现你全部陋习。
2.熟练使用好各种辅助工具，但不要全部依赖工具，最主要是学习分析和设计的思考方式
3.注重单元测试，关注程序性能,可维护性,可测试性是编码技能提升重要手段
4.通过重构使编码过程形成完整闭环的反馈回路，重构能力可以很好体现自己的设计能力
5.养成良好习惯，形成自己的编码过程检查单，多请教老员工可能事半功倍。

40 signs you really are a lousy PHP programmer

This is something I prefer to call my "programming list of shame". Although having a formal university education with courses on software engineering, enterprise software architecture & database design I have been guilty of every single one of those things at one time or another. This is completely subjective & Eclipse oriented

You are a lousy PHP programmer if you

1. don't comment your code properly with something like phpDoc


2. don't see the need and/or benefits of a good programming IDE like Zend Studio or Eclipse PDT


3. have never used some form of version control like Subclipse


4. don't adopt some coding & naming standards and general conventions and stick to to them at least throughout the project


5. don't use a consistent methodology


6. don't escape and/or validate properly input or sql queries


7. don't plan your application thoroughly before starting to code


8. don't use test-driven development


9. don't program & test with error reporting on


10. don't see the benefits of a debugger


11. don't refactor your code


12. don't keep the different layers seperated using something like MVC


13. don't know what these stand for: KISS, DRY, MVC, OOP, REST


14. don't return content but echo or print it from your functions or classes


15. have never seen the advantage of unit tests or testing in general


16. return HTML, not data, strings, or objects.


17. hard code messages and configuration parameters


18. don't optimize your sql queries


19. don't use __autoload


20. don't allow intelligent error handling


21. use $_GET instead of $_POST for any destructive actions


22. don't know how to use regular expressions


23. you've never heard of sql injection or cross-site scripting


24. don't allow simple configuration, can be parameters passed to a class’s constructor, set/get methods called later, or constants defined at a runtime.


25. don't understand the benefits and limitations of Object Oriented Programming


26. misuse OOP / everything you write , no matter how small is OOP


27. you think reusable software equals/requires your code to be OOP


28. don't choose intelligent defaults


29. don't have one single configuration file


30. don't want the file contents to be seen, but give it a .inc extension instead of .php


31. don't use a database abstraction layer


32. don't keep it DRY, Don't repeat yourself. If you have to copy and paste or duplicate something your design may be off.


33. don't make a function/class/method do just one thing and don't make them interact.


34. don't try to take advantage of OOP specific features like abstract/interface classes, inheritage polymorphism & access modifiers.


35. don't optimize your application design with established design patterns


36. don't allow your user to define a base directory if you have multiple files and/or directories


37. pollute the global namespace, one option is to prefix the functions in your library with a common string


38. don't allow a table prefix when using database tables


39. use a separate template engine


40. don't take a look at established php frameworks for inspiration, most of them have advanced web dev concepts and good code