g t*_*g t 23 c# attributes coding-style obsolete
我最近被告知在我们的代码中使用该[Obsolete]属性标记了许多方法是不好的做法.这些方法是我们代码库的内部方法,而不是API.这些方法处理旧的加密功能.
我觉得向团队的其他成员表示不应该使用这些方法是一种快速而安全的方式,并提供了建议替代方案的信息.
其他人认为我应该完全删除这些方法,根据需要重写或重构现有代码.此外,人们认为很容易忽视编译器警告.
当第三方没有使用代码时,是否存在将代码标记为过时的"最佳实践"？或者这主要是主观的？
Jon*_*nna 27
步骤1.将成员或类别标记为[已废弃]
步骤2.更新成员或类的所有内部使用,以使用替换过时方法的新方法,或将该成员或类本身标记为[已废弃]
步骤3.如果您在步骤2中将新内容标记为[已废弃],请根据需要重复此步骤.
步骤4.删除所有过时的成员和类,这些成员和类既不公开也不被过时的公共成员或类使用.
步骤5.更新文档以更清楚地描述建议替换任何公共过时成员或类的方法.
最后,您将不会有内部代码单独使用的过时代码.没有什么可说的,你必须一次完成所有这些; 在每个阶段你都取得了进步.从开始步骤1到结束步骤5之间的时间可以是5秒或5年,这取决于许多因素(大多数因素与复杂性有关).
顺便说一句,如果有人发现很容易忽略编译器警告,问题不在于[已废弃].但是,长期不在代码中留下这样的调用的一个原因(即,尽可能地完成第2步)是为了确保人们最终不会习惯于编译器警告,因为他们是编译代码的习惯性反应.
我认为这是主观的.如果它是内部的并且是一个相当快速的过程,那么我会执行更改.
但是,我也遇到了相应的重构需要更长时间(整个代码库中的许多调用)的情况,在这种情况下我使用了该[Obsolete]属性.在这种情况下,新开发将使用新函数和任何有时间执行重构的人,直到所有调用都消失,这意味着可以删除该方法.
小智 6
这取决于.是的,您可以重构代码.您可以...吗？
问题是 - youCAN重构在一个程序中.如果API在公共场所出局并且您根本无法使用API重构代码则要困难得多.这就是Obsolete的用途.
如果API是代码的内部API,那么重构就是最佳选择.CLean up代码,不要乱七八糟.
但是,如果公共API发生变化,它应该 - 如果可能的话 - 应该慢慢完成.
其余的仍然是主观的.我不喜欢内部API的"过时".