On being Culture Aware

Normal

0

21

false

false

false

FR

X-NONE

X-NONE

Share/Bookmark

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?

Share/Bookmark

This entry was posted in CQL rule, Culture, FXcop. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.gridpulse.com Bogdan

    This is a good rule indeed.
    I’ve hit this problem more than once, as it’s really easy to forget about it.

  • http://www.paraesthesia.com Travis Illig

    I use both FxCop and NDepend (run in that order) and usually end up disabling the rules that are redundant. If FxCop, for example, is going to fail the build anyway, no need to re-run the rule in NDepend and clutter the report.

  • http://codebetter.com/members/mob/default.aspx Mike O'Brien

    I noticed most of your blog posts talk about NDepend either directly or indirectly, so I was thinking there was some sort of affiliation.

  • http://codebetter.com/members/Patrick-Smacchia/default.aspx Patrick Smacchia

    Mike the company SMACCHIA.COM SARL, I am the CEO of the company and lead developper of the product. See the NDepend website if you are interested in the product:
    http://www.ndepend.com/

  • Steve Py

    Should probaby add the TryParse and Convert.To* methods that also accept format providers.

    As for a default CQL, why not. :)

  • http://codebetter.com/members/mob/default.aspx Mike O'Brien

    So do you own the company that makes it?

  • http://codebetter.com/members/Patrick-Smacchia/default.aspx Patrick Smacchia

    Commercial. There is a free version for OSS projects and students.

  • http://blog.mikeobrien.net Mike O’Brien

    Is NDepend a commercial product or is it free/OSS?