任何代码都是值得学习的，哪怕它很乱、很差，你也能从中学习到怎么乱、怎么差，你怎么在你自己的代码里规避它。作为入门道的程序员请不要动不动就哭着喊着要让人家开源（真开源了你看得懂嘛？），不要认为所有不是自己写的代码都一无是处，什么都要自己重新再写一套。

发了些牢骚，接下来列举一些我认为wordpress做得让我感动的地方，算是对代码用我的小红笔圈圈点点吧。如果你觉得你都知道了，或者太简单，就请当做这是我的自我娱乐吧。

• define( ‘ABSPATH’, dirname(__FILE__) . ‘/’ ); 定义了很多全局常量作为可配置的代码，而具体实现不会有过多的硬代码（就是写死的地方）。我的项目中的配置参数一般会用一部分全局常量，另外一部分用变量，因为有些数组的情况。wordpress里尽可能用的是常量，因为这样值不会被后面的代码所改动，使用一个全局变量全靠自己自觉，谁没事儿改一下就乱了，也没有办法控制。所以想办法全部定义成常量试试。我原来是比较担心这个东西不在程序开头实现，再加上一些逻辑是否可行？实际是可以的，所以“定义全局常量来避免程序中的硬代码”。而且这样还有一个好处，就是在一些类方法或者函数中调用这个值时，不用每次都要global这个变量了，因为常量是全局的，无需特殊声明。按照编码惯例或者规范，常量一般都用全大写的字符标示，分割单词使用下划线，这也方便在程序内辨别那些是常量。
• dirname(__FILE__)，很久前就在使用这个参数用于include，require了，这样写相当于是当前编辑的文件所对应的路径以及需要包含文件的关系。所以你知道你当前编辑的这个文件的位置就能推导出包含文件的路径。wordpress没有在每个程序文件包含时使用相对路径，而是在根目录下的wp-load.php一次性获取一个根路径并定义在常量中。其它程序文件用这个作为定位的基础。
• wordpress没有完全转向面向对象的编程，2.0.0开始才引用了一些新的类来构建系统，而为了兼容性，旧的一些面向函数的代码还存留在系统中。所以现在从头运行的过程是顺序的：index.php -> wp-blog-header.php -> wp-load.php -> wp-config.php -> wp-settings.php -> new WP() -> WP::init() -> WP::main() -> template-loader.php相信未来会全面向面向对象转换。
• 目录结构非常之简单，根目录下的程序都是直接可以请求调用的，相当于访问入口。子目录wp-admin里面都是管理系统的代码。wp-includes里面都是核心程序的代码，类库，函数库，业务核心逻辑代码。wp-content目录保存的是所有跟站点、用户相关的代码，包括模板，风格，汉化包，用户上传的文件等。可以说这样分离业务数据可以轻松实现升级。以后升级保留wp-content目录的所有内容，覆盖新的程序代码，运行一下/wp-admin/upgrade.php解决一些版本之间需要调整的数据结构，数据等内容，就可以完成升级了。
• 本地化方面有两个细节，如果写死在代码里的翻译，前后加了/*WP-I18N-XXXX*/的注释，方便用程序查找替换。没有写死的都被替换成__(‘xxxxx’)这样的函数样子的内容，其实这个双下划线加括号是映射到gettext()函数。具体用法可以参考php手册。至于怎么生成 .po语言包，我还没有研究，稍后有空可以看看。
• wordpress一大特色就是支持很多插件，你也可以遵循api文档，为它编写插件。插件支持的实现方法主要是有通用的函数负责注册不同位置需要调用的函数数据，然后在很多地方写下调用处理插件程序的钩子入口hooks，触发钩子代码后就会检查对应这个地方需要调用那些预注册过的函数，调用后才会继续运行程序。这样你的程序只要按照文档注册，就会被在适当的地方调用。它不像discuz的实现，discuz是在不同代码位置使用eval来执行注册好的程序，插件代码写入数据库中进行管理了。wordpress是基于php程序文件的，并且有更高的注册机制管理这些需要触发的插件代码。值得学习。
• 模板或者样式方面没有使用第三方类似smarty替换标签的方法实现，而是将显示部分的代码混合尽可能简单的php调用代码来组合成模板文件。使用load_template()函数来调用。无需定义标签并和实际程序映射，需要自己实现页面级缓存机制代码了。我是比较喜欢smarty的，所以推荐使用smarty，哈哈。

粗略看了一下，没有全部看完，再继续看到心得会继续编写同类文章。happy coding!