如下列截图的画红圈部分(点击图片可显示全图)，我在开发中一直都是这种书写方式。我喜欢把关联性强的语句，都写在同一行，用;号隔开。如画红圈的这片程序，如果换成流行的每句都回行，变量名用有含义的变量名，这片程序需要2页以上。类似的情况，有很多这样的程序篇帖容量，换成流行的每句都回行、长变量名需要3、4页。正是这种短篇幅、短变量名，我个人的体会是，才使开发速度提高到原来的2～3倍，越是复杂的程序，这种方式的优势越明显。

使用有含义的变量名，在开发中要花费非常多的时间来命名，因为需要的变量特别多，而且程序多了，容易错乱。

因此，无论有没有含义的变量名，该出问题还是一样出问题，可读性其实差不多一样，解读程序的时间差不多，甚至我觉得一直用$a1，$a2，$c1，$e1这样可性读更高。例如$a1，$a2，$b1，$b2，$c1，$c2，$a，$b，作为局部变量；$e1，$e2作为全局变量；$s1，$s2作为更大的、include文件里的全局变量；$d1，$d2作为include文件里的全局变量。

当然，这种短变量名更适合于独立开发者，有利于更高效地开发；但有可能不太短合团队协作开发。

独立开发者和团队协作开发的程序，优点各有秋千：
独立开发者的作品，更容易实现高效，冗余代码更少，缺点是修改起来基本上只有作者能修改，因为编写完整的开发文档，花费的时间至少是开发时的5倍，所以通常是没有开发文档的；

团队协作，因为多部门之间有各种合作，甚至和营销、运营部门也是一个整体，所以团队协作能完成更多的工作量，也容易赚到更多的资金回报，但缺点是程序效率相对低很多，冗余代码也越来越多，现在有很多的软件、手机APP，80%以上都是冗余代码，也有冗余代码超过90%的例子(流量大的知名网站)。
团队协作因为参与的人数多，更容易成就为成功的产品，哪怕是一些技术上存在着重大的瓶颈、或瑕疵，比如现在很多的手机APP就是这个例子，只要宣传到位，无论技术好坏，稍微包装一下就是很高大上的产品。
团队协作的程序、软件，虽然功能越来越多，但是也越来越臃肿、越来越卡，有一个原因可能是重构的成本大，也不重视优化。

团队协作的程序，其实也有相应的作者，如果没有开发文档，同样较难二次开发。

这个截图的文件，是Feedval阅读器最核心的一个程序，路径是func/updatb.php。这个程序，以前在2016年，2017年曾经开发过一部分。单是这个程序，累计大约7～15天完成。它的作用是更新RSS，然后写到数据库，要写入8组数据库。写入8组数据库的这部分，因为有重复写入的部分，所以用了2个自定函数。

前几个月发现这个程序又有个bug，大部分RSS更新时不会重复加载过的RSS，只有少部分RSS有此问题。现在一定要修复这个bug，于是翻出了这个程序。

修复bug的过程，还是和开发程序时一样。因为很多程序写完，第二天就忘掉大部分了，需要重新解读。解读完之后，找到相应的部分，然后一边修改程序，一边做大量的测试。

其实不用说第二天忘记，离开电脑几个小时，很多都忘了。

因为程序本身的语句多，工作量庞大，一个程序完成后立即关闭窗口，然后进行下一项(依然是复杂的工作)，所以容易忘记。

其实不是记不住，是程序太多，记不过来；二是没有去记。

程序难解读的一个原因
因为语句的编写顺序，无法在成品程序里体现；思路也无法在成品程序里体现。