Static code analysis is a beautiful thing. For a while now Visual Studio has it embedded and it is only a right click away.
By default each project gets assigned “Microsoft Managed Recommended Rules” as baseline for analysis. In my opinion this is really good choice for most of projects. It does include quite a few checks (61 to be exact) and whatever you get is almost certainly something you want to improve.
I would argue that most projects would benefit from setting bar quite a bit higher at “Microsoft Extended Design Guidelines Rules”. This ruleset gets annoying pretty fast when you run it on existing project. You can almost be sure that code will be peppered with CA1704: Identifiers should be spelled correctly and CA1062: Validate arguments of public methods.
First one can be sorted with small code analysis dictionary and second one will need few ifs here and there. All other warnings can also be sorted with similar level of effort since they are not real errors nor something that will cause immediate problems (e.g. double dispose). If project is old this can take ages and it is for little or no practical value.
Biggest beast is “Microsoft All Rules” setting. This one will complain for anything and everything and it will be really hard to satisfy it in any GUI project. Yes, it is possible but this purity brings no value to customer and I usually keep my main assemblies away from it.
I have quite a simple personal rules which level to use. If assembly is intended to serve as a framework that will be written in stone once it is released I go with “Microsoft All Rules”. It is annoying at times but users of your framework will be thankful because it forces really tidy external interface.
If assembly is intended for sharing between projects I go with “Microsoft Extended Design Guidelines Rules”. It forces me to keep design guidelines close to mind and to avoid some potential bugs that can just creep in code (e.g. returning internal array directly). All externally visible members should be held to higher standards since you never know when you or someone else might reuse them.
If given assembly contains GUI, I usually just stick to default Microsoft Managed Recommended Rules. GUI assemblies are not intended to be called directly and bunch of warnings will be just annoyance (e.g. localization warnings when localization is not even planned).
Your mileage and opinion might differ but one thing is for sure - any project has to have at least minimum code analysis enabled.
PS: As number of rules increases so will number of false warnings. Suppressing code analysis warnings is sometime only way to go around it. Just make sure you have really good reason. If you have too much (valid) suppressions that might as well mean that you selected wrong code analysis level for your project.
PPS: It is not always clear which rule belongs to which ruleset. Therefore I have prepared small Excel file with this information.
Converting from date to string in C# is really easy. Basic components are yMdHms and you go from there:
var date =newDateTime(2008,3,1);
Console.WriteLine(date.ToString("yyyy-MM-dd"));//2008-03-01
Console.WriteLine(date.ToString("yyyy"));//2008
Console.WriteLine(date.ToString("MM"));//03
Console.WriteLine(date.ToString("dd"));//01
Of course you can also use format without leading zeros:
var date =newDateTime(2008,3,1);
Console.WriteLine(date.ToString("yyyy-M-d"));//2008-3-1
Console.WriteLine(date.ToString("M"));//March 1 (or something similar) - WTF?
Console.WriteLine(date.ToString("d"));//2008-11-01 (or something similar) - WTF?
Looking at first line one would expect d and M to give day and month without leading zero. In .NET these characters lead double life. For example, if d is given alone it really means standard date and time format specifier. Similar goes for M.
Solution is quite simple. If you really need to use them alone, just prepend percent character (%):
var date =newDateTime(2008,3,1);
Console.WriteLine(date.ToString("yyyy-M-d"));//2008-3-1
Console.WriteLine(date.ToString("%M"));//3
Console.WriteLine(date.ToString("%d"));//1
I am big fan of Mercurial and I keep all my private projects under its control. Quite a big portion of them is done in Visual Studio so I needed something a bit more integrated than TortoiseHg. Best solution I have found was VisualHg. And I was happy user until Visual Studio 2012 came out.
No matter how many times I would install and reinstall, it would not appear under Plug-in Selection. It seems that VisualHg installation is broken a bit so it does not signal Visual Studio to refresh list of source control plugins.
Solution is actually easy. Install VisualHg as you would usually do. When you start Visual Studio 2012 just go to Tools -> Extensions and Updates. In online section there you can find HgSccPackage. I actually don’t like this one but installing it does refresh plugin list. After HgSccPackage install is done, VisualHg is once more available for selection.
Most of car rentals have a contract with other companies where companies get various discounts and addons in exchange for continuous business. It is good deal for everybody involved. But sometime curious things happen.
For example company I work for has benefit of “Monthly charge up to 31 days”. Simplified it means that your rental comes at cheaper price a bit earlier. For me that has an even better benefit of getting reimbursed on month basis. In ideal world, if I rent car on 1st, I get an receipt on the same date next month. Except it isn’t so.
For some reasons National has also an policy of closing each contract every 30 days. If you imagine a world where some months have a day longer you will see a problem. Let’s assume my rental starts on September 1st. First bill is due on October 1th. Next bill after that is October 31st. One after that is November 30th. Congratulations, you have just lost a day.
In reality this is not really an cost issue. Although you have monthly rate actual calculations are still done per day so everything evens out. However, person has an interesting choice between sending to accounting two bills for all months that have 31 day or sending them “monthly” bills that end on funny dates.
It only shows that for system design you must consider edge cases (and test for them) or users might get confused…
Almost two years ago .NET Reflector went into freeware history. First it was $35 but price has gone since to $95 these days. For something that was freeware once this is quite an increase.
Strictly speaking I was not really affected. Microsoft released source code for basic .NET libraries quite a long ago so most of my snooping needs were covered. But setting that up was pain-in-the-ass compared to the pure simplicity of .NET Reflector.
JetBrains, creators of ReSharper tool, created new tool called dotPeek. For all practical purposes we can view it as long lost cousin of .NET Reflector. Best of all it is completely free (at least in version 1.0).
Product is not without fault. On Windows 8 I could not get document search to work; source produced has extra spaces here and there; it does not support Visual Basic; there is no option to save a file; project export is not possible; it sometime breaks Alt-Tab behavior… Those are just biggest complaints that show it is definitely not without fault.
But I like it nevertheless!
It worked perfectly on all code that I gave it and has always produced acceptable code. Stack trace browsing allows to track function calls across assemblies with ease and it is feature that I never thought of before but it seems so logical now.
Browsing though code is probably as good as it gets once you get used to keyboard shortcuts. And editor support for code folding is fantastic. Since that is what you actually need 95% of time, all bugs / forgotten features are easily forgotten.
It is tool that is worth its place in toolbox of every C# programmer.
P.S. No, it does not have stupid time restrictions that drove me crazy even in freeware .NET Reflector.