Hi Rob,

Yeah just learned about CodeIt.Right last friday and am using it to bring mojoPortal into conformance with the standard set of fxcop rules.

When I started friday there were 7721 violations and at the moment I'm down to 1619 (in the core features) and am hoping to get it down to 0 either today or tomorrow.

Part of the reason that I'm trying to get it all done at once is because changing names of things in an API can break other developers custom modules so those who have their own custom features are going to need to change their code after this. I don't think it will be difficult to fix using some find and replace, but I think making changes to the API need to happen pretty much all at once so that we don't break things repeatedly over time. This may be an aggravation to some and I may take some heat for making these changes but I think the long term benefit of coming into compliance with these rules is worth it because once we achieve compliance it will be much easier to stay in compliance as we go forward and this improves the quality of the code. I also plan to revise my Codesmith templates when I finish this cleanup so that we generate compliant code.

About a year and a half ago I tried to use FXCop but because it found so many violations it was looking like a huge daunting task to get into compliance and it was hard to try and be compliant even going forward because the new violations were in the same huge list as old ones. So CodeIt.Right seemed to provide an opprotunity to reduce this task to a doable level though I've got almost 3 full days into the cleanup as of now I figure even if it takes 2 more it will be worth it.

Most of the issues that developers will face with their custom features will be things that have changed the name to comply with the rules, so for example siteSettings.SiteID becomes siteSettings.SiteId so a find and replace of .SiteID with .SiteId will fix all of that particular one.

I've already had to fix some in the Survey feature and then I saw you made some commits to the survey feature so I figured once I cleanup the rest of the core I will get your latest code for the survey and fix it again to make sure I don't lose any of your work. The changes I make int he first round will be just to fix where I've broken things in Survey with my changes in core. After that is done and you have it synced to your sandbox, you are welcome to help fix violations within Survey. That would be great.

So I'm hurrying to finish this so that if there is going to be some pain for other developers its relatively all at once instead of strung out over time. I hope most developers understand the benefit and will be willing to bite the bullet and make the needed changes in their own code without getting too frustrated with me. I think already some of the breaking changes have made it to trunk so I'm trying to get the resto f them done quickly so they can all be dealt with at once. I would say that of the thousands of changes to come into compliance the vast majority are not breaking changes and have no impact on custom features but things in the SiteModuleControl base class, SiteSettings, PageSettings SiteUtils etc do potantially and probably impact custom features.

Best,

Joe

Well, yes I plan to follow up with FxCop but for now I'm still plowing through the lower hanging fruit that CodeIt.Right finds. Actually there is not much low hanging fruit left and the remaining erors are taking longer and longer to fix. Some things I don't dare chage unless I'm ready to do a lot of testing and other things I'm not sure I'm going to change even if it means I can't get to 0 FxCop violations. For example they don't like my mojoPortal namespace or any classes that start with mojo, they want it to be Mojo but I'm not all that inclined to go along with it. Also these tools find things that are just not problems like if you have method GetSPParameters(..) it suggests renaming to GetSpParameters but after you do it it suggests changing it back! So some human judgement still must prevail.

Cheers,

Joe

Hi Rob,

I think those are usually associated with code that uses .ToString()

I'm not usre the best way for all data types but for int variables I think the way to resolve it is to use

using System.Globalization

.ToString(CultureInfo.InvariantCulture)

InvariantCulture tells it not to use the current culture but to toString it in a culture neatral way which is virtaully always what we want with ints and probably other data types too unless there is a specific reason to format it to the current culture. I guess if its being displayed in the ui you might use the current culture in some cases like .ToString(CultureInfo.CurrentCulture)

Best,

Joe

ps I ran FxCop and there are way more violations than what CodeIt.Right found. Kind of disheartenting. I'm burnt out from doing this grunt work for a week and need to move on something more rewarding for now but plan to do more and more over time in the late part of the day when my mind is less creative and gradually continue to fix these.