有哪些诡异的php代码风格

一、为了写更少的代码

笔者（我，本人，在下，人家）在开发中，一直在探索诡异与新奇的代码风格。致力于同样的功能使用更少的代码实现，为自己省ATP，为服务器省代码空间，为老板省钱。

出自于我手中，最经典的一句当然就是将

写成

还有其他一些神奇的代码，比如在判断的同时进行赋值，方便判断成功后继续使用。例如将

写成

在长期的使用thinkphp框架的过程中，深深地体会到，自己没有使用到这个框架的精髓。从来都是一个模块下分Controller和Model，然后来了一个功能A，就建一个AController和一个AModel，一点新意都没有。

倒不是说这样写就是错了。就算完全抛弃Model，把所有代码写到Controller中，都是正确的，因为代码可以运行，前端可以拿到数据。但如果把所有代码都写到Model中就不一样了，这么写的都是傻逼。

二、控制器与模型分离写法

后来我的代码发展出了另外一种风格。假设我们有两个模块，分别是

Backstage（后台管理系统）

Moment（帖子模块）

帖子模块中一切正常。现在有一个新的业务需求，就是需要在后台管理系统中可以对帖子进行管理。

按照之前的架构，就在Backstage模块中建立一个MomentController和MomentModel，然后分别写代码，这都没有问题。新的架构是，在Backstage\Controller中写MomentController，在Moment\Model中写BackstageModel。因为控制器是与前端交流的，这个功能在接口上属于Backstage。但模型属于后端，是与数据库交流的，在模型上这个功能属于Moment。所以采取了这样分开写的方式。

在功能出问题的时候，根据错误信息，大致可以断定是控制器出现错误还是后端逻辑又或者是数据库方向出现错误，根据这个架构，可以很快找到出错位置。

在这个架构使用了快半年的时候，代码又混成了一锅粥。虽然还是可以debug，但很明显，当初的架构并没有起多大作用。

这只是又一个“我的代码风格很诡异”的例子。

三、人名水果名各种名命名法

再举一个更诡异的例子。

在早期刚学会写php的时候，写程序的时候总是步步为营。说白了就是每一步程序都要声明一个变量。因为每一步都有可能出bug，所以对自己很不自信，声明很多变量，就是为了方便出bug的时候下断点。

变量多了，就不知道怎么起名了。于是，英语书上的人名、水果名等等就都出现在了我这一篇代码中：

四、用无聊的写法来打发无聊的编码时光

下面是老夫年轻时候写的软件测试实验的代码。

做实验的时光真的很无聊，这种无聊的时间，谁能做得有趣，那才真的有意义。

还有人生巅峰连6个表，注释明显是在向老板亮剑。

还有可怜巴巴的向老板亮剑版本。

五、每个注释都是一个故事

话说程序员都讨厌两件事：

1、写注释

2、同事不写注释

我可能是一个假程序员吧。

我就特别爱写注释，而且写起来注释乐此不疲。我觉得注释简直是程序员界的福音。你能想象得到，从同事手里拿来一整篇诡异的代码（比如我写的），然后一行注释没有，整篇代码就像圣经一样摆在眼前，是什么感受么？我感受过，我不想看，我跟老板说，我不看别人代码，我选择重写。

在我们最新版的代码架构中，Application目录下会有一个Template模块，这个模块时不允许任何人编写的。这个模块中存放的是模板。每次需要建立新的模块，都只要复制这个文件夹，再改名就可以了。

在新的代码架构中，我规定任何一个模块都要有一个readme文件，以便别人查询。这个提议也得到了另外一个后端的认可，并且没有拿泰拳打我。因为Template也是一个模块，所以在Template下也会有一个readme，里面写了如何使用这个模板模块。

在Thinkphp框架中，每一个Controller下的方法，都对应一个前端所需要的接口。因为还要写接口文档，所以我干脆选择把注释写得干净利落。比如下面这张图。

这样写完全部注释，就可以直接复制到接口文档里了。

所以，一个好的文档规范，真的可以增加团队协作的效率。

作为一个前后端都写的人，表示就算不团队协作，有接口文档给自己用也很舒服啊。

六、php 的面向对象代码风格

最近正在尝试一种新的风格。既然php是面向对象的语言，而Thinkphp正是利用了这个特点才得以实现。那我们干嘛不善加利用这个特点呢。

为了体现这一部分的重要性，我把这一部分的内容单独写成另一篇文章，与这篇娱乐文章一起发。

所以，见下篇文章。