问候。
我想记录代码中的某些模式，以便建立一致的术语（以便简化与软件的通信）。但是，我不确定在哪里定义给出的术语。为了达到同一水平，例如：
我有一个代码生成器。此代码生成器从分析器接收某个InputStructure（是的，名称InputStructure可能不太理想）。然后将此InputStructure转换为各种后续数据结构（如验证过程的抽象描述）。这些数据结构中的每一个都可以转换为相同数据结构的另一个值，也可以转换为下一个数据结构。这应该在某种程度上听起来像管道和过滤器 鉴于此，我调用一个采用数据结构并将相同数据结构的值构造为转换的操作，而我调用一个采用数据结构并生成不同的后续数据结构的操作。导出包含代码的字符串的最后一步称为发送。 （因此，整体而言，代码生成器采用输入结构并进行转换，转换，派生，转换，派生和最终发出。）
我认为强调这些术语对于沟通是有益的，因为那时很容易谈论事情。如果你听到“转型”，你知道“好的，我只需要考虑这两个数据结构”，如果你听到“发射”，你知道“好的，我只需要知道这个数据结构和目标语言。”。< / p>
但是，我在哪里记录这些模式？当前代码库使用访问者并提供名为ValidatorTransformationBase＆lt; ResultType＆gt;的类。 （或InputStructureTransformationBase＆lt; ResultType＆gt;，等等）。
我真的不想在接口上添加这些术语的定义，因为在这种情况下，我必须在每个接口上重复一遍，这显然违反了DRY。
我正在考虑通过添加更多接口来强调转换和派生之间的区别（我必须考虑一个更好的TransformationBase类名称，但我可以认为像ValidatorTransformation扩展ValidatorTransformationBase＆lt; Validator＆gt;或ValidatorDerivationFromInputStructure扩展InputStructureTransformation＆lt; Validator＆gt;）。
我还认为我应该在已经存在的doxygen文档中添加自定义页面，如“词汇表”或“架构原则”，其中包含此类原则。唯一的缺点是贡献者需要找到这个页面才能真正了解这一点。
我错过了可能性，或者你认为我在这里判断错误了吗？
- 问候，Tetha
答案 0 :(得分：0)
您可以将它们放在包中定义这些接口的package.html文件中。你可以在包层次结构中走得更远。
答案 1 :(得分：0)
我已经看到一些开源软件附带 README-developers ，这是开发人员的自述文件，其中包括词汇表，RCS，wiki网址等等。