Juval Lowy, on Friday, gave a talk about Being more productive with the .Net framework. The session was "simulcast" on the web. Juval contends that most books focus on the raw technology, and this talk is dedicated to things that can enhance productivity when programming with .Net. Below are the tips and tricks that he explained in the talk.
WinCV - the utility shows header-life information. If you need to search for a type, you can search for it. You can load your projects in WinCV by modifying the config file. In VS2005, there is a mouse menu item "Go To Definition". VS will open the class headers in the code window. Using the "Code Definition Window", you can hover on any type, and VS will put the class headers in the docked window.
WinDiff - Get your VS 6.0 CDs, and copy WinDiff to your box for use in comparing code files. Better than the comparer in VSS.
Animation Speed - The default speeds are a little slow, so go to Tools, Options, and put animation speed all the way up.
Multiple Startup Projects - in solution properties, you can launch multiple startup projects and have the debugger attach to them all for simultaneous debugging.
Linked Files - Every project has its own AssemblyInfo.cs, and you'd like your version number to be the same. Create a SolutionInfo.cs file with all the shared attributes and link the SolutionInfo.cs file into the project, and it will get compiled with the project.
Solution Directory - when creating a new project, VS puts it in a directory with the project name. If you click the "more" button, you can select a solution name and check "Create directory for Solution", and it will give a cleaner solution hierarchy.
External Tools Integration - Automate invoking of external tools. Go to tools -> external tools. Give the name of an EXE to be invoked. Don't hard-code the name, but insert a macro to insert, for instance, the assembly name. Then, more options will appear on the Tools menu.
Treat warnings as errors - Make level 4 warning for building. This should be the default setting.
Derive classes from Component to enable drag and drop - Inherit from System.ComponentModel.Component. Then you can use .Net data access designers with that class. If you hold down the alt key, you can use rectangular selection of code.
Editing config files - When viewing an app.config file, use the Document Outline to show a stepped outline of your Xml file. You can use this for Html as well.
Search hidden text - When doing a find, select "Search hidden text", and it will search inside closed regions of code.
Conditional Compilation - Exclude a method call from compilation. Use System.Diagnostics. Stay away from #ifdef. ConditionalAttribute is a method-level attribute that controls whether or not to compile the method. Lines that call the method also become conditional.
Event Accessors - Instead of raw event member, use add/remove accessors like properties. It promotes encapsulation and loose coupling. C# has this. VS will have this in 2005. Use property-like accessors for delegates. Don’t expose your member variables. You wouldn't expose fields, so don't expose fields that are a delegate either.
Windows Forms Opacity - Every visible control has an Opacity property. It can make the window translucent or completely transparent. One use if if when you close a form, you want to have the window fade away.
Name threads - naming threads can be very useful in debugging. If you have multi-threaded code, and you hit a breakpoint, you don't know what thread you are on. Give it a name as well.
Thread name breakpoint - Go to breakpoint window and make a conditional breakpoint. Set the condition to "System.Threading.Thread.CurrentThread.Name == "MyThreadName" In 2005, breakpoints have a filter command where you can use ThreadName = "MyThread" There are certain tokens you can use. By default, this feature is disabled in 2005. Tools->Option->Debugging->Enable breakpoint filters.
Killing a thread - Do not call Abort(). Abort() does not allow graceful exit. Does not allow error handling. Abort() is not guaranteed to run. Make a custom Kill() method. Should set flag and wait for thread to terminate. Abort() has another flaw. The thread can do indefinite processing in catch{ }. Juval went through a custom class that he uses to abort the thread.
Have a coding standard - Naming conventions and style, coding practices, project settings and structure, framework-specific guidelines. The standard should be thin on Why, and rich in What. Minimize harm. You can use the Idesign coding standard at www.idesign.net.
Import/Export Settings in VS - Tools->Import and Export Settings. This will make it easier to have everyone on the team using the same IDE settings. VS has team settings file. You can automatically reapply if newer version is available.
Language Version - You can restrict the Visual C# version. The default in 2005 is C# 2.0. ISO-1 is C# 1.0 (VS 2002). If you have a VS 2003 application, you can use VS 2005 to maintain this application by going to the project settings->Build->Advanced->Language Version. Selecting ISO-1 is the C# 1.0 standard. You will use the older compiler and it will ensure you don't use new language features. Good for maintaining an olde rapp.
Interfaces factoring and design - One big class is a bad design. A bunch of little things unrleated is a bad design too. When designing, you pay for the cost of building a unit, and you pay for integration. A large number of modules is a high cost to interface (effort). A low number of modules has a high cost/module for effort.. You need middle ground. If you graph the two lines, you have an area of minimum cost. You want to be there. The key is properly factoring the interfaces for the modules. When factoring, think in terms of reusable elements. Interface factoring results in interfaces with fewer members. Just one member is possible, but avoid it. Optimal number is 3 to 5 members. In the .Net framework, interfaces have more methods than properties. You need a ratio of at least 2:1. The exception is an interfaces with properties only - should have no methods). Avoid defining events. On average, .Net has 2.75 members per interface. The methods to properties is 3.5:1. Less thatn 3 percent of the members are events. On average, .Net framework interfaces are well-factored. Someone also did a survey on the JDK. On average, they have 4 members per interface.
