是否有C#静态分析工具来捕获不满足功能要求的API？
作者：互联网
我最大的烦恼之一就是API,它无法像普通用户那样理解API的功能.
案例：.NET的DateTime.ToUniversalTime.文档令人恐惧：
On Windows XP systems, the ToUniversalTime method recognizes only the current adjustment rule when converting from local time to UTC. As a result, conversions for periods before the current adjustment rule came into effect may not accurately reflect the difference between local time and UTC.
后来继续说：
On Windows XP systems, the ToUniversalTime method recognizes only the current adjustment rule for the local time zone, which it applies to all dates, including down-level dates (that is, dates that are earlier than the starting date of the current adjustment rule). Applications running on Windows XP that require historically accurate local date and time calculations must work around this behavior by using the FindSystemTimeZoneById method to retrieve a TimeZoneInfo object that corresponds to the local time zone and calling its TimeZoneInfo.ConvertTimeToUtc(DateTime, TimeZoneInfo) method.
这必须是有史以来创建的文档中最搞笑的一句话.使用ToUniversalTime()时,谁不需要精确的本地日期和时间计算？为什么不只用ObsoleteAttribute标记此方法？
无论如何,我正在寻找的工具是可以用程序集级元数据标记程序集的工具,例如[RequiresHistoricallyAccurateLocalDateAndTimeCalculationsAttribute].然后,如果它找到ToUniversalTime()的任何实例,则将它们标记为编译器错误,就像C#不允许我在没有不安全注释的情况下直接访问非托管代码一样.
解决方法:
该要求似乎更适合代码分析,而不是属性修饰或编译错误.
查看：http://www.binarycoder.net/fxcop/html/index.html
This has to be the single most hilarious sentence of documentation
ever created. Who doesn’t require accurate local date and time
calculations when using ToUniversalTime()? Why not just mark this
method with ObsoleteAttribute?
考虑到日期/时间计算的性质/复杂性,这并不是一个特别令人恐惧/震惊的启示.
如果要在Windows XP或任何其他操作系统上进行UTC处理,我首先应该熟悉平台的特质,就像处理几乎所有其他复杂操作一样.给定的替代方案(TimeZoneInfo)也不是防弹的,因为它高度依赖于平台.
关于TimeZoneInfo的平台依赖性…我指的是OS.
当您开始进行时区转换(由此引发许多与日期相关的问题)时,您将使用FindSystemTimeZoneById之类的方法.从正面来看,方法名称清楚地表明您正在使用本地系统(因此可能不太含糊)比ToUniversalTime()).但是,会向操作系统查询时区列表,因此操作系统可能会返回错误列表(我相信Windows中的注册表中包含的值),列表已过时(也许是打补丁的机器) )等
我注意到Windows XP与TimeZoneInfo似乎也有ambiguity问题(请参阅“呼叫者注意事项”)：
On Windows XP systems (…) As a result, the method may not accurately report ambiguous time
offsets for periods before the current adjustment rule came into
effect. For more information, see the Notes for Callers section in the
Local property.
并且(如您所指出的),底层平台的实现可能存在缺陷.
此外,时区由字符串ID引用.尽管这些变化似乎并没有太大变化,但仍有可能在应用程序中存储“魔术字符串”,而这些字符串不再与时区匹配.
至少那是我所发现的,尽管我对这个主题的了解还远远不够.我对.Net和Windows Server上的通用时间的使用感到很积极.
我的观点是,通常有充分的理由说明BCL(基类库)作者以某种方式实现了事情,即使确实导致了意外的行为.另一种选择是完全省略功能.
如果您认为这是一个陷阱,那么我认为值得花时间缓解它.
标签：static-analysis,c 来源： https://codeday.me/bug/20191101/1980086.html