【发布时间】:2009-10-26 16:51:15
【问题描述】:
我们正在使用带有内置静态代码分析规则集的 VS2008。
我们有一个相对较大的 C# 解决方案(150 多个项目),虽然一些项目(
在此先感谢,
--Ed.S.
【问题讨论】:
-
不需要“编程”标签。如果您想在这里提出一个不符合该标签条件的问题,那就不要。 :)
标签: c# visual-studio-2008 code-analysis static-analysis
我们正在使用带有内置静态代码分析规则集的 VS2008。
我们有一个相对较大的 C# 解决方案(150 多个项目),虽然一些项目(
在此先感谢,
--Ed.S.
【问题讨论】:
标签: c# visual-studio-2008 code-analysis static-analysis
您应该为项目激活的第一条规则是那些您在该项目中还没有任何违规行为的规则。这将使您避免引入新问题,而无需花费任何额外的清理工作。
至于其余部分,鉴于您已经在其他项目中使用代码分析,对于哪些规则最有可能被破坏并导致严重后果的最佳输入可能是从事这些项目的开发人员。如果项目之间没有足够的重叠来从开发人员那里获得有意义的反馈,您可能需要考虑从 Visual Studio 2010 中的 Microsoft Minimum Recommended Rules 规则集中包含的规则开始。
如果您计划实际清理任何给定项目中的现有违规行为,您可能需要consider using FxCop instead of VS Code Analysis 直到清理完成。这将允许您立即激活规则,同时将现有违规行为排除在源代码之外。
【讨论】:
鉴于 Studio 的规则类似于 FxCop 的规则,我可以告诉你我会最后打开哪些。
如果没有国际化,请关闭全球化规则。
首先关闭性能规则。需要时进行优化。
让其他人适应您的团队和项目。关闭不适用的个别规则。特别是命名规则可能需要调整。
编辑:最重要的是减少噪音。如果每个项目都有 200 个警告并保持这种状态几个月,那么每个人都会忽略它们。打开对您的团队很重要的规则,清理代码以获得 100% 的通过(或抑制异常 - 会有异常;这些是指导方针),然后强制保持代码清洁。
【讨论】:
如果您要本地化您的项目/它将在不同国家/地区使用,那么一定要启用本地化规则。它将找到对所有类型的未指定 CultureInfo 的 Format/Parse 函数的所有调用。在测试中很难找到涉及未指定 CultureInfo 的错误,但是当您的法国客户会问:为什么您的程序在使用“,”作为小数分隔符的数字上无法运行/崩溃时,它们真的会让您大吃一惊。
【讨论】:
根据我的经验,所有类型的代码分析警告都会显示代码中的“隐藏”错误或缺陷。解决这些问题可以解决一些实际问题。我没有找到要禁用的警告列表。
相反,我会一次将它们打开一个项目并修复该项目中的所有警告,然后再进行下一个。
如果您想关闭某些功能,我会考虑不检查命名规则(除非您要发布库、API 或其他外部公开的方法)和全球化规则。 (除非您的应用程序积极使用全球化)。这在一定程度上取决于您的情况,这是有道理的。
【讨论】:
我有点同意Jeroen Huinink's answer。
我会启用您认为项目应遵循的所有规则并尽快修复它们。您现在不必全部修复它们,但是当您修复缺陷或重构模块中的方法时,您始终可以清理通过静态分析在该方法或模块中发现的问题。新代码应遵守您的规则,现有代码应尽快转变为遵守规则,但您无需放弃一切来实现这一点。
您的开发团队还可以查看项目的问题并确定它们的优先级,也许在您的问题跟踪系统中针对最关键的问题提交缺陷,以便由适当的开发人员快速解决。
【讨论】: