防止其他开发人员在类中使用基方法答案

【问题标题】：Prevent other developers using base methods within a class防止其他开发人员在类中使用基方法
【发布时间】：2010-02-04 15:01:53
【问题描述】：

我有一个使用文件系统实体来操作数据的类。我们有几种方法专门设计用于（尝试）处理我们在这种方法中面临的一些问题（文件锁定、不存在的文件等）。理想情况下，如果其他开发人员尝试直接通过 System.IO 而不是使用辅助方法访问文件系统，我希望能够发出警告。

这可能吗？我正在寻找的行为是有效地将诸如 File.ReadAllText() 之类的方法标记为已过时，但仅在此项目中（不是解决方案范围内）。

我已经进行了一些挖掘，看起来我唯一的选择是“告诉他们确保他们使用你的方法”。我希望有人能给我一个不同的，更有帮助的答案。 :)

--编辑-- 自定义 StyleCop 或 FxCop 规则的建议很好，但不幸的是在这种情况下不切实际（并非部门中的每个开发人员都使用这些优秀的工具），并且进行文件访问的合法方法 do 使用 System .IO。在合法方法中添加“忽略”属性也是一个危险的想法。如果有人看到我如何“破坏”我自己的规则，他们很可能会将属性复制到他们自己的方法中。

【问题讨论】：

假的。为了使用 System.IO，您必须首先在using 中或直接引用它。因此，在代码审查期间您需要做的就是为System.IO“查找所有文件”。
事后考虑，您可能会通过故意引入冲突来毒化命名空间，但这似乎比它的价值要麻烦得多。
一个有趣的想法，但“授权”方法也必须使用 System.IO。在代码库中发现非法用途可能很棘手。
“授权”方法将单独构建在允许具有 System.IO 引用的库中。
嗯，我突然想到这只是分层的一个特例。防止（例如）UI 层在不通过规则层的情况下接触 DB 层的方法是将它们保存在单独的库中，并拒绝让 UI 库作为一个整体来引用 DB 库。同样，您可以编写一个文件 I/O 层，然后从其他项目中删除对 System.IO 程序集的所有引用。这样，即使他们添加 using 或指定范围，它也会失败。是的，内省可以避免这种情况，但这本身就是一个危险信号。

标签： c# attributes obsolete

【解决方案1】：

使用静态分析工具（例如StyleCop 或FxCop）和rule 捕获“不要直接使用System.IO”。然后将其集成为您的自动构建过程的一部分，如果有人尝试直接使用System.IO，则抛出。没有人喜欢破坏构建。

【讨论】：

太好了。希望你也喜欢修复它。
我喜欢这个主意。不幸的是，我们（作为一个组织）还没有强制在构建上运行 StyleCop 或 FxCop（我们应该，而且我一直在推动它，但改变是一个缓慢的过程）我想我可以修改这个想法并将其添加到我自己的规则集，但后来我成为这个模块的单点 QC。
我发现的问题是，所有静态分析工具都会在谨慎方面犯错，因此真正的应用程序可能包含一个文件，其中包含用于覆盖特定投诉的命令。这使您处于需要检查覆盖的有效性而不仅仅是代码的位置，这会在不缩小问题的情况下解决问题。
@ZombieSheep：您在构建过程中有任何代码分析吗？您能否编写一个简单的脚本作为构建过程的一部分来搜索System.IO 并在找到时抛出？基本上为这一规则手动滚动您自己的静态分析工具。这并不难，而且是朝着采用真正的静态分析工具迈出的一小步。
别误会，我们确实使用 StyleCop 和 FxCop - 但绝不是全面的。问题是决定我们可以安全地忽略哪些规则，以及我们必须遵守哪些规则

【解决方案2】：

您可以为 FxCop/Visual Studio 代码分析编写 custom analysis rule，并将其作为自动构建的一部分运行。

【讨论】：

是的，或者在 TFS 中将其作为签入的要求。

【解决方案3】：

嗯。我自己没有尝试过，但是如何通过使用“隐藏”真正 System.IO 的命名空间别名来强制人们使用您的自定义文件处理类。如果我没记错的话，这些都是在项目级别应用的。

【讨论】：

这听起来有点像“命名空间中毒”的想法。问题在于，即使假冒的 System.IO 阻塞了最直接的路径，也可能有某种方法可以指定真正的 System.IO，因此这可以防止意外绕过自定义文件 I/O 层，而不会阻止真正的 System.IO想做。这包括那些认为问题是错误，而不是故意的功能（或将声称这一点）的人。
啊，是的，我没有注意到你的评论。这是你的意思吗？我不明白你会如何阻止人们故意在他们的代码中手写所有内容以访问 System.IO 命名空间而没有它。
查看我的下一条评论，我建议从参考列表中删除带有 System.IO 的程序集。
不过，人们很容易将其添加回来，以为它是一个错误或被意外删除了。

【解决方案4】：

不确定这些建议是否有效，因为我从未做过，但值得深思：

这不就是“企业模板”的设计目的吗？难道他们不允许您制作一个限制允许的项目引用的策略文件吗？

或者，虽然并非万无一失，但您能否向项目添加一个预构建事件，如果引用 System.IO 则会引发警告？

【讨论】：

【解决方案5】：

您能否向源代码控制提交挂钩添加一些自定义功能？它不会发现现有的违规行为（如果有的话），除非这些文件被更改但应该检测到新的用途？

有什么好处吗？

【讨论】：