我想说,对于大多数用途来说,
@author是不需要的噪音。API的用户不应该-也许不应该-关心或想知道谁编写了哪些部分。
而且,正如您已经说过的那样,SVN已经以比代码更权威的方式拥有此信息。因此,如果我是团队中的一员,我将始终喜欢SVN的日志,而忽略
@author。我敢打赌,无论您采用哪种策略,代码都将与现实不同步。遵循“不要重复自己”的原则,为什么将这些信息放在两个地方?
但是,如果出于官僚或政策原因必须将此信息包含在代码中,那么您是否考虑过在
@author签入时自动更新代码中的标签?你可以 或许
与SVN钩子实现这一目标。例如,您可以列出所有更改给定文件顺序的开发人员;或更改最多的人;管他呢。或者,如果
@author您在外部发布的(源)代码中强制执行,则可以考虑将
@author自动添加作为发布版本的一部分(我怀疑您可以某种方式从SVN中获取此信息)。
至于添加多个类
@author标记(或其他注释),我会说您会积累很多无用的声音。(同样,您有SVN。)
以我的经验,识别历史更改(例如对一行代码或方法的更改),然后找出与之相关的更改集(以及哪个跟踪记录),会更加有用。然后,您具有更改的完整上下文:您拥有故障单,更改集,可以在同一故障单上找到其他更改集,或者大约在同一时间可以找到相关的故障单,并且可以看到所有更改形成了那个工作单元。您永远不会从代码中的注释或注释中获得此信息。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)