Normal 0 21 false false false FR X-NONE X-NONE

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 decimal.

// <Name>Float and Date Parsing must be culture aware</Name>

WARN IF Count > 0 IN SELECT METHODS

FROM TYPES "System.DateTime",

           "System.Single",

           "System.Double",

           "System.Decimal"

// The NameLike CQL clause operates on the signature

// "methodName(type1,type2...typeN)"

WHERE (NameLike "Parse\(" OR NameLike "ToString\(") AND

      !NameLike "IFormatProvider"

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 in mind.

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?