用途：在编写、审查或维护代码注释时使用，目标是让注释提升可维护性而不成为负担。适用场景包括为新代码添加注释、审查既有注释质量、建立团队注释规范、优化注释密度，以及处理性能敏感代码的注释。
核心原则：意图优于重复。注释不应复述代码做了什么，而应在其更高抽象层说明意图，像书的标题或目录一样起导航作用，帮助后续维护者理解原作者意图。若代码本身已说清一切，重复代码的注释没有价值。
注释类型：标记注释用于提醒未完成工作（如 TODO、TBD 等标准化标记），需可机械搜索并纳入发布检查清单；解释性注释用于复杂、棘手或敏感代码，但应先尝试重构让代码更清晰；摘要注释把多行代码浓缩为一两句，便于快速浏览；意图注释在问题层面说明某段代码的目的，如“获取当前员工信息”对应“更新 employeeRecord 对象”；元数据注释记录代码无法表达的信息，如版权、保密声明、版本号、设计说明、需求引用、在线参考、优化说明及工具要求的注释（如 Javadoc）。
可维护风格：避免需要手工对齐的高维护成本样式，如用省略号连接变量与说明、用星号框包住段落、用加号下划线等。原则是准确优先于美观。语法上，Java 和 C++ 单行注释用 // 并保持简短，多行注释用 /* ... */ 比手工换行的 // 更易维护；强调可用编辑器宏生成标准长度行。
注释密度：IBM 研究结论是每约 10 条语句 1 条注释最能提升清晰度，过少难以理解，过多反而降低可读性。不要强制“每 5 行至少 1 条注释”之类配额，那只是治标，根本在于代码是否清晰。
性能：不要因性能担忧（如解释型环境、网络传输开销）而回避注释，可另建发布构建，在构建过程中用工具自动剥离注释。
伪代码编程过程中的注释效率：有效 PPP 自然形成“每隔几行一条注释”，注释数量是过程的副产品而非目标；不必数注释，只需评估每条注释是否有效，若注释说明了“为什么”并符合上述标准，数量即足够。
限制：资料未提供具体安装命令、平台支持、收费方式或价格信息。