文本化

设计将应用数据存储在永久存储器中的文件格式

---

在协作程序中（可能通过网络）传递数据和命令的应用协议

数据文件元格式

为了简化存储的序列化操作发展得来。

---

DSV风格
RFC822格式
Cookie—Jar格式
Record—Jar格式
XML
WindowsINI格式
Unix文本文件格式的约定

应用协议元格式

简化网络间事物处理的序列化操作发展得来。

---

HTTP
BEEP
XML—RPC，SOAP和Jabber

透明性

为透明性和可显性而编码

• 程序调用层次中最大的静态深度是多少？也就是说，不考虑递归，为了建立心理模型来理解代码的操作，人们将要调用多少层？如果大于四层，就要当心。
• 代码是否具有强大、明显的不变性质？不变性质帮助人们推演代码和发现有问题的情况。
• 每个API中的各个函数调用是否正交？或者是否存在太多特征标志和模式位，使得一个调用要完成多个任务？完全避免模式标志会导致混乱的API，里面包括太多几乎一模一样的函数，但是频繁使用模式标志更容易产错误（很多易忘并且易混的模式标记）。
• 是否存在一些顺手可用的关键数据结构或全局唯一的记录器，捕获了系统的高层级状态？这个状态是否容易被形象化和检验，还是分布在数目众多的各个全局变量或对象中，而难以找到？
• 程序的数据结构或分类和它们所代表的外部实体之间，是否存在清晰的一对一映射？
• 是否容易找到给定函数的代码部分？不仅单个函数、模块、还有整个代码，需要花多少精力才能读懂？
• 代码增加了特殊情况还是避免了特殊情况？每一个特殊情况可能对任何其他特殊情况产生影响；所有隐含的冲突都是BUG滋生的温床。然而更重要的是，特殊情况使得代码更难理解。
• 代码中有多少（意义含糊的常量）？通过审查是否很容易查出实现代码中的限制（比如关键缓冲区的大小）？

透明性和避免过度保护

调试和探测开关的存在是良好程序的标志