A typical development pitfall comes
from forgetting about the culture setup of the machine on which the code is
executed in production (typical it works on my machine
mistake). Imagine that a program running on a French machine stores a float as
the string “3,14“. The float value cannot be restored from the same program running
on a US machine. It would expect the string to be “3.14“ with a dot, not a coma.
To prevent such mistake in the
NDepend code I
created the following CQL
rule. Basically, it forces the code base to use only Parse() and ToString() methods that accept a parameter of
type IFormatProvider. As far
as I know, the problem occurs on DateTime, float (Single), double and
// <Name>Float and Date Parsing must be
WARN IF Count > 0 IN SELECT METHODS
FROM TYPES “System.DateTime”,
// The NameLike CQL clause operates on the signature
WHERE (NameLike “Parse\(“ OR NameLike “ToString\(“) AND
With this rule set up, in the future
we won’t forget about caring for culture when converting from/to string.
Previously, I already wrote a post concerning this Nurture Knowledge Database agile state
FxCop has a similar rule named
Specify IFormatProvider. We are inclined to append this CQL rule to the set of default CQL rules, what is your opinion?