评论方法：如何评论应用程序中其他地方使用的内容？
我的 IVR 应用程序包含许多全局变量，这是不可避免的供应商提供的框架的副作用。因此，在很多情况下，变量在一个 JSP 上被赋予值，并且在调用者深入应用程序的多个对话框之前不会再次被触及。
当我必须添加或修改这样的变量时，我会留下描述修改的序言注释，而不详细说明整个功能：
<%--IVRAvenger 20100927 Issue#:12345: Keep track of what the caller entered. Used for multiple ID/ID change logic, further on. --%>
<assign name="gblIDInput" expr="memberID"/>
这是否具有误导性？简单地添加这些小语句，并让其他开发人员扫描这些变量发挥其（可疑）魔力的模块的代码是否会更好？
谢谢，
IVR复仇者
My IVR app contains a lot of global variables, as a side effect of an inescapable vendor-supplied framework. As such, there are a lot of cases where a variable is given a value on one JSP, and is not touched again until a caller has gone several dialogs deep into the app.
When I have to add or modify such a variable, I leave a preamble comment that describes the modification, without going into detail on the whole piece of functionality:
<%--IVRAvenger 20100927 Issue#:12345: Keep track of what the caller entered. Used for multiple ID/ID change logic, further on. --%>
<assign name="gblIDInput" expr="memberID"/>
Is this misleading? Would it be better to simply add these small statements, and let other developers scan the code for the module where these variables work their (questionable) magic?
Thanks,
IVR Avenger
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于这样的问题，我会推荐一个外部字典文档，其中列出了全局变量、目的以及与其相关的典型工作流程。
您可能还想列出使用这些变量的主要模块。虽然这些数据会过时，但它将为难以维护您的应用程序的人提供一个起点。
如果您确实实现了这样的文档，我还会推荐代码所体现的任何总体模式或理念。包括已知的错误选择以及为什么它们是错误的选择不会有什么坏处。由于大多数开发人员不会阅读（当然也不会维护）这样的文档，因此您要么是为新员工（将文档作为一项任务）编写，要么是为未来的维护人员（最终因沮丧而无法实际阅读文档）编写文档。
With a problem such as this, I would recommend an external dictionary document that lists the global variables, the purpose and typical work flows associated with them.
You may also want to list the major modules that use the variables. While this data will get out of date, it will provide a starting point for somebody having difficulty maintaining your application.
If you do implement such a document, I would also recommend any overall patterns or philosophies that are embodied by the code. Including known bad choices and why they were bad choices wouldn't hurt. Since most developers won't read (and of course maintain) such a document, you are either writing for the new hire that was given documentation as a task or a future maintainer that has finally gotten frustrated enough to actually read the documentation.