views:

147

answers:

5

We want our coders to NOT use DateTime.parse().
How can we block to use it?
Can we override this, to hide from them?

EDIT1
Actually we want to override this method, we have our own method which gets called this way: clsStrUtils.ISOToDate().

EDIT2

We do trust our programmers, but this is a specific situation. I don't want to restrict no-one using a better way, I just want to restrict Parse(). They can still use ParseExact().

+5  A: 

Do you have a continuous integration system? If you do, you could mark a build as failed if a style check check does not pass. Make sure to scan for references to "DateTime.Parse" in your style check.

A better solution would be to unit test your code. DateTime.Parse has plenty of valid uses, and it might be better to just make sure tests cover them.

Stuart Branham
We want to force them to use something else.
Pentium10
If there are cases that your ISOToDate() method covers that DateTime.Parse() does not, make sure those are represented in tests, then. Other than that style checking is the only solution I can think of. There shouldn't be a way to do it during development time, unless you want to hack your compiler or something.
Stuart Branham
A: 

If you are doing code reviews, which you should be, you can catch it during the review. Otherwise, there is no way to prevent someone from calling a static method in the .NET Framework (that I'm aware of).

Randy Minder
We want to force them to use something else.
Pentium10
+1  A: 

It is my experience that "forcing" programmers to use something only inhibits their thought process and causes resentment to grow throughout the group.

Aaron
We understand that, but they do miss a lot of things and causes us lot of problems with this call. So we have written our own method and we must ensure they use this.
Pentium10
Your answer confirms your age. At 22 I probably felt the same way. So forcing programming to adhere to processes, best practices and team standards causes resentment to grow? Any team that has this problem needs to grow up a bit and shed the 'wild west' mentality of software development.
Randy Minder
If that's the case, I say that you should do a better job of hiring competent programmers or be better at teaching them proper technique. I for one would never want to work with someone who doesn't trust me and would rather modify the .NET framework than to show me proper ways of doing things.
Aaron
Hire better, more honest programmers. Or - do it yourself. You shouldn't have the power to modify the .net framework
Eric
@Randy - If anything, my age only further illustrates the need to properly teach me rather than to modify the .net framework. What message are you sending to someone when you force them to use something different rather than sitting them down and teaching them proper technique? I may be young and not as experienced as you, but I certainly know that this is not the proper way to go about things.
Aaron
We do trust our programmers, but this is a specific situation. I don't want to restrict no-one using a better way, I just want to restrict Parse(). They can still use ParseExact().
Pentium10
+6  A: 

You might be able to write a custom rule in FxCop to do this. Check out the tutorials on this site for information on how. You then might be able to run it periodically to validate that the members of the team are using the standards you put in place.

Nick
+1  A: 

We've started using FXCop and, speaking as a developer, it's not so bad. It should be able to easily block the usage of certain methods.

Ad Hoc
Oops. I didn't see Nick's answer. http://stackoverflow.com/questions/2299851/how-to-block-usage-of-datetime-parse-from-coders-on-visualstudio-project/2299955#2299955
Ad Hoc