引语：代码风格，是一个工程师长期以来养成的一些编写代码的习惯，其实并无绝对的好坏之分！但是，基本上可以这么说，一个有很好的代码风格的人，技术水平绝不会太低；反之，一个没有好的代码风格的人，技术水平也不会高到哪里去，即使是他已经有很多年的编程经验！因为，在业界有一个不成文的现象，那就是每个工程师都有一个追求技术提升，追求完美的梦！结果就是，随着个人技术水平的提高，风格也越来越成熟，而这个风格就体现着其个人水平！

　　本文以PHP语言的某微视角，说几个代码风格上的事，同理可推至其他语言，其他技术，甚至其他通用道理！

　　本文将以从面到线再到点的过程，讲述一些个人心得。仅供大家娱乐参考，如有不对，请多多指教。如有雷同，不胜荣幸！

　　本文就以一个虚拟项目作为线索吧！

　　1、面：所谓面，就是面对一个项目摆在眼前，怎样去部署大方向的问题的思路！准确的说，这里并不是真正地体现一个代码风格，而是一个做事风格！

　　　　风格1：1. 我需要需求书，书上怎么写，我就怎么做；2. 如果有一些未知的技术，尽量让需求上做一些让步，以减少开发难度；3. 找个牛逼的人，带着自己或其他人一起做；4. 时间是多久？

　　　　风格2：1. 我需要需求书，书上写的东西，清楚吗？有什么可要可不要的东西，有副作用吗？2. 大概需要什么样的辅助工具，在哪里可能会得到这些东西？3. 我怎样组建自己的技术团队？4. 时间是多久？5. 后期可能会有什么样的扩展？

　　2、线：所谓线，可以理解为流水线吧。就是怎样去完成这么一个计划，怎样调动生产？

　　　　风格1：1. 设计数据库； 2. 选择代码框架；3. 编码；

　　　　风格2：1. 设计服务架构；2. 模块细化；3. 设计数据库； 4. 选择代码框架；5. 编码；

　　3、 点：所谓点，其实才这里说的真正的代码风格，将着重说明一些。

　　　　风格1：任性，随意而为，没有规则！

　　　　风格2：着重讲解！

　　　　3.1. 不一定非要使用现有成熟框架，但是一定要有MVC的概念，基本要抛弃面向过程编程方式，采用面向对象，不任性；

　　　　3.2. 结合多种设计模式进行开发，如单例模式、工厂模式、抽象模式、观察者模式等等，这些都是成熟的概念，都要尽量多用！优雅，大气，效率，易读；

　　　　3.3. 类内部变量定义以权限放第一位，变量修饰符放第二位，以重要程度分先后，如 public static function fun1(){} ；类名与文件名有某种特定程度的相同，方便查看；类名统一首字母大写；私有变量或方法使用下划线开头以区分，如 private function _doCut($data)；文件以最能体现其功能的单词命名，区分类型，如 IndexController.class.php, function.inc.php;

　　　　3.4. 文件内部使用统一命名方式，要么使用下划线方式命名，如 $get_child,$bind_value，要么使用驼峰式命名，如 $getChild,$bindValue；变量名尽量使用全名不要使用简写，如 getCategory不要简写成getCat；

　　　　3.5. 多个参数之间有逗号分隔时，逗号后要留一个空格如 fun($param1, $param2);运算符两边均有一个空格(数组对齐除外)，如 $click = 123；

　　　　3.6. 避免使用global变量，尤其是有些不是公共初始化时产生的变量；

　　　　3.7. 杜绝函数内部include方法文件，因为这样很难找到真正起作用的方法，或者说方法混乱；

　　　　3.8. 使用自动加载方式，而非include方式；

　　　　3.9. 如果一定要包含文件，尽量使用include_once,require_once 避免一个文件被引入多次从而报错情况；

　　　　3.10. 对可能多次引用的全局变量，使用某类的静态方法进行获取，如 ConfigClass::get('main', 'field'); 对于数据库一类连接，使用静态变量，保存首次连接时打开的连接，从而多处使用DB实例时，仍然不会重复实例化，如 $db = ConfigClass::getDbInstance();

　　　　3.11. 多使用isset(), empty()等系统函数进行判断空操作而非 !$var, $var == null;

　　　　3.12. 对于使用两次以上方法，就应该去考虑提出到公用地方或者类中；

　　　　3.13. 数据查询先确认当前索引，配合写SQL，特别地方，一定加上注释；

　　　　3.14. 会使用文件锁，数据库锁，会使用缓存如  memcache, redis, mongodb等；

　　　　3.15. 会适当使用事务；

　　... 

　　好吧，晚了，洗洗睡吧。有空再补补。总之，一些小细节，总是要用经验堆砌才会真的明白！

　　其实，好与不好，大家已早有定论，只是作个参考，罢了！

　　习惯，就好！