说实话， 我还从来没有见过另外一个行业的工程师，如本行业一样，动辄对同行的作品彻底否定。

见过了太多的PLC编程工程师，公开声明自己的原则：不愿意读别人的程序， 不爱修改别人的程序，情愿另起炉灶自己从头编写程序。

理由就是：别人的程序， 烂。

至于原因么， 很简单， 别人的编程水平不行，就我的最好。

包括我自己。

我自己记忆最清晰的是两次现场救援，系统原本的程序烂掉了， 跑不起来，原来的程序员干不下去了， 撂挑子不管了， 我来接了烂摊子。 因为摊子本来就烂， 所以不得已，毁掉了原来的所有程序， 只保留了符号表， 所有程序从头做的。

除此之外， 只要系统原本是能运行的，无非有缺陷， 总出事情， 那也尽量在其原本基础上读懂， 修改。找到问题， 解决问题。 别人的程序再烂， 我想也总有一些可以参考学习的闪光点。

不过也确实有些程序烂到实在不像话。 读那种程序， 实在是要忍着恶心的。有那么几年， 我一边读这种程序， 心里一边暗暗排名，哪个是我见过的第一烂的程序， 哪个是第二烂。 也曾经长时间的在硬盘上保留着，仅仅是为了作为比烂的样本。打算谁要发起比烂大赛， 拿出来参加的。

但我也实在明白得很，这种专业技术人员之间互相倾轧的心态是要不得的， 是自古以来的文人相轻的陋习的传承。 我还没有不要脸到只要别人的程序都烂， 只有我的程序最好， 最完美最合理最优雅最简洁。

所以， 这里面一定有一个客观衡量的标准。

这些年， 我一直在寻找， 在思考。

首先，要找到最合理， 最理想的程序范本。

最终我认为， 是PCS7 。 使用PCS7高级工具生成的程序， 最终落到S7-400的PLC中，其本质上还是PLC程序。  尽管其代码规模大，不够精简，运行效率低，但是从编程的规范来说， 它一定是最合理的。

其次， 是从中提炼出其可度量的好的标准。

好的程序， 一定是模块化的，面向对象的， 层次分明的。 PCS7显然是依循这一点做的。但还不足以作为考量程序好坏的标准。

我最终总结，认为，好的程序的标准是：不使用M中间量，不使用Timer。

我不希望有人给我耍滑头， 耍脑筋急转弯。说， 不让用M量，可以啊， 那我用全局数据块， 建立数据， 一样可以。 也用DB块自己脉冲计数， 也可以绕过不使用TIMER。

那性质是一样的， 特征都是：全局变量。

如果学过高级编程语言， 就会知道， 高级语言里面最基本的原则就是少用全局公用变量。 尤其禁止在函数块与函数块内部使用PUBLIC变量来交互数据。

放到PLC环境， 其实说的就是M和T。

我自己以前做程序， 程序块基本上靠M和T做出来的。为了清晰，便于传承， 给每个FC块严格分配了可以使用的M区和T区域。

现在看来， 都是属于落后的编程思想。也害了不少跟在我后面学习的徒弟。 惭愧。

那么如何避免使用M量和T呢？答案是大量使用FB， 每一个设备，单元类型，均提炼做成类库，需要的存储区使用FB块内部的静态变量，而定时器则使用SFB的定时器， 背景数据来自FB的多重静态数据。

那么是否可以完全做到呢？PCS7显然是可以做到。 而我自己做过的程序， 也有做到过没有使用1个M和1个T的。 CPU中指定的系统变量不算。

偶尔也有偷懒， 不够追求满分。 特别是调试到后期， 一些小的细节的功能， 顺便就用M量简单实现了。那怎么办呢？内心给自己的程序打个分扣上5分就可以了！

当你掌握了客观评价标准，都能给自己扣分了，那么就可以理直气壮地评价别人的程序了。 比如你如果见到我10年前的某个程序， 规定了多少M区不许使用，就可以尖锐地指出：烂！