编制程序，简单生活
好的编程文档将会使你的编程生活更加轻松。增加梯级评论及描述标签可以帮助理解代码及程序。通常，如果一个编程者有一个项目时间进度表的话，编制文档将不是问题。但是当时间马上就要截止，程序员需要将代码快速写出去调试，他可能会认为等以后再写文档，但是，“以后”可能再也不会到来。
在调试代码时编写文档是不切实际的。在调试时，首要任务是确保代码的功能和满足客户的过程需求。在同一台PLC上多个程序员编程也会对文档造成一些困扰，需要通过程序员之间的沟通和协调使文档的损失最小化。
己所不欲，勿施于人
文档可以帮助客户和程序员理解正在发生的事情或代码的意图，这是非常重要的。我建议思考问题时，可以假设自己就是程序员。
通常的，你编好程序，并且调试成功，你会从现场离开而且很长一段时间你不会回到这里。
如果你是编程者，你觉得必须你亲自回到现场去增加一些新的代码容易呢？还是这些代码在几年后会被其他的人轻而易举的理解，从而不用你亲自去修改容易呢？你公司的其他的程序员和你的客户的分包商都是一样的。当然了，我们也可以写出非常晦涩难懂的代码并且没有文档的注释，这样可以让其他的人在任何程序更新和改变时持续地依靠你。
这可能听起来对于代码的安全性来说非常好，但是操作起来并不理想。客户不会对这种只依赖某个人的状态表示感谢。客户通常希望非定制产品配件，以简化维护和减少停机时间，同样的概念也适用于编程。客户通常会避开定制软件，并倾向于开放的源代码和良好的软件支持，从而减少未来可能出现的潜在停机和升级时间。
代码：保持简洁
对于文档，另外一个好的建议是经常性的管理：保持代码的简洁，去除一些标签及冗余的代码。对于程序员来说，我们通常会对于新的项目高度关注，特别是那些并没有预先设定程序结构的项目。毕竟，为什么做推倒重来这样的“傻事”呢？但是实际上，我们需要剔出我们可以剔出的任何无用代码。
作为一个程序员，如果文档不全或者根本没有的话，进入一个程序是非常困难的事情；即使将代码逆向工程后也没有帮助，因为你发现存在一定比例的伪码或不需要的代码。经过一些痛苦的尝试，你会问自己的第一个问题就是，“这到底是谁写的代码？”请不要做这样的程序员。
良好的文档编程和管理是很好的编程习惯。我猜大家一定都遇到过在没有一点文档参考的情况下编写程序，往往需要通过逆向工程花费很多时间才能获知这个程序的用途。有总比没有强，即便这个文档是用你所不熟悉的外语编写的，至少还可以参考，因为Google翻译就能搞定这个问题。
