I just came across the news this morning. I used Reflector a lot when I was first learning .NET. Lately, I’ve been using it with the Graph and DependencyStructureMatrix plug-ins to figure out where applications are too tightly coupled. I’m glad it’s staying free to users.
Tag: software development
An Alternative to NUnitForms
I first heard about Project White from someone at the Agile 2008 conference last week. I haven’t had a chance to play with it yet, I’m very curious to see how it compares. Since it comes from Thoughtworks, I think it’s going to be good. If it makes testing of modal forms and dialogs easier, I’m already sold.
If anyone out there has already been using Project White successfully, it would be great to hear from you.
Writing the contents of a string to a text file
I should have assumed this existed, based on Ed Poore’s comment on this post, but here’s the actual command:
System.IO.File.WriteAllText
There are multiple overloads for it, but the most basic one is: File.WriteAllText(filePath,contentString).
NDbUnit Revisited
I first wrote about NDbUnit back in 2006. Unfortunately, it doesn’t appear much new has happened with the project since then. The current version (1.2) is still a great help for unit testing when you need to put a database into a known state. If an application you’re testing uses strongly-typed datasets as its data access layer (DAL), integrating the use of NDbUnit into your existing unit tests is even easier because it uses XSD files.
I’ve revised my previous sample project using Visual Studio 2008. You can download the source as a zip file. Make sure you have NUnit (I used version 2.4.7) and NDbUnit installed before you attempt to run the sample tests.
A couple of “old-school” CS principles
Robert Martin is a guy our CEO and architects really respect when it comes to software design and development. Somehow, I managed to not have heard of the guy before this year, so I’ve started reading his stuff. Here are a couple of his older columns that may prove quite useful if you find yourself building APIs in your work:
- The Open-Closed Principle (in PDF format)
- The Liskov Substitution Principle (in PDF format)
The first one explains a lot of the issues I’ve seen with applications in previous jobs. In any number of applications, a simple change would have a ripple effect that touched a lot more than just one line of code. Following the open-closed principle more strictly would haved save me many headaches.
Strongly-typed DataSets in Subversion
Strongly-typed datasets are the default option for creating a data access layer (DAL) with the various .NET versions of Visual Studio. From the XSD file that defines a strongly-typed dataset, Visual Studio generates a [XSD].Designer.cs and [XSD].xss. They’re regenerated every time you change the XSD, even if you just change the layout. This can become a problem when working in teams and it’s necessary to merge changes. If your Subversion repository is configured to version the generated files, they’ll be marked as conflicting when you update.
These are the steps I’ve taken to merge changes in the situation above:
- Delete [XSD].Designer.cs and [XSD].xss.
- Resolve conflicts in the XSD file (and mark them as resolved). This will generate new versions of [XSD].Designer.cs and [XSD].xss.
- When resolving conflicts in the files generated in step 2, use the whole file that was just generated.
This will be much easier than trying to resolve conflicts in generated files.
Changing Primary Keys from “int” to “uniqueidentifier”
I’m in the process of doing this for a project that uses Microsoft SQL Server. One of the “gotchas” I came across was that once you’ve switched from “int” to “uniqueidentifier”, @@IDENTITY and SCOPE_IDENTITY references won’t work. The second response in this thread pointed me in the right direction. You have to call NEWID() in the context where you need it (and save the value) in order to be able to refer to it later.
Refactoring
Last night, I went to a presentation on refactoring by Jonathan Cogley. My notes are below:
refactor – improve the design of existing code incrementally
Code must:
- do the job
- be maintainable/extensible
- communicate its intent
Code that doesn’t accomplish all of the above is broken.
Refactorings
- rename
- extract method
- inline method
- introduce explaining variable
- move method
- inline temp
technical debt – anything that needs to be done to the code that gets put off until a later date
I found a much better definition for technical debt. It makes a nice argument in favor of refactoring (though not as good as it would be with some way to quantify and measure it).
code smell – indication that something could be wrong with the code
Code Smells
- duplicated code
- long methods
- large classes
- Too many private/protected methods
- Empty catch clause (FxCop flags these by default)
- Too many static methods
- Variables with large scope
- Poorly-named variables
- Comments
- Switch statements
- Unnecessary complexity
Even though comments in code to tend to get out of date, I’m not sure I’d call them a code smell. Wikipedia has another definition of code smell, along with a link to a taxonomy of code smells.
When to refactor:
- before a change
- after all current tests are green
Sometimes, refactoring is necessary to understand code.
reduce scope – bring variable closer to where it’s used
Be sure your unit tests don’t re implement what the tested code is doing.
Eliminate double assignments (a = b = 0) for clarity.
Each method should have only one operation/concept.
If you must use code comments, they should explain the “why”. The code should be clear enough to explain the “what”.
Favor virtual instance methods where possible in your code.
Avoid using the debugger. Write unit tests instead.
Performance improvements tend to make code harder to understand. Don’t use refactoring to address application performance.
Recommended reading:
Null Coalescing Operator
I didn’t know about this C# 2.0 operator (??) until ReSharper suggested it as a replacement for a particular use of arithmetic if (?:) that I’d added to some code recently. I already prefer C# to VB.NET because of its terse syntax and stricter compiler, so this discovery tipped the scales just that much more.
The most recent blog post Google coughed up for this operator is this one, from Aaron Zupancic. Aaron links to another post that demonstrate its use for viewstate.
TeamCity 3.0
Now there’s a freeware version of it that supports up to 20 users and build configurations. We were looking at setting up CruiseControl.NET again for continuous integration at work, but this will be much easier.