Seens like PDC 2007 has been postponed to a later date.
And this was the year I was all set up to go.
Well, I’m an optimist. This will make the TechEd Developer in Barcelona, Spain a better experience.
I’m Portuguese and most of the software I design and develop is about concepts in Portuguese. How should I name stuff?
If I’m talking about Conta or Cliente it’s easy: Account and Customer. And what about concepts that aren’t in English or for which a translation would be unrecognizable?
When I name stuff I try to make things easily recognizable for those who read it, and this brings us to a combination of both Portuguese and English.
When someone finds in the code or documentation ContaInválidaException (names are in Unicode, it’s time to let go archaic prejudice – “conta invalida” means that the account is making something invalida and “conta inválida” means that the account is invalid) identifies immediately what it is. For a business person it’s obvious that it’s something about an invalid account and for a technology person it’s obvious that it’s some kind of exception.
Following up on a previous post, this time I’ll give you my naming conventions for partial class files.
There are two main reasons for me to break a class definition into more than one file. The main one is when I have inner classes and the other is when the file is getting too big.
How should I name the files? The usual tendency is to use a “.” as separator. This looks nice until you came across something like this:
If I would extract the inner classes and use the “.” as separator, I would end up with the following list of files:
And, what about the long event handling code? Should I do the same? If so, I will end up with the following list of files:
This doesn’t look very nice, does it?
So, here is my proposal:
This way, I end up with the following list of files:
And this looks a lot nicer.
You can download here.
Before you get too excited, according to Tom Hollander, this is really just a maintenance release addressing a small number of issues discovered since the release of 3.0. Here is a summary of the main changes:
I’m a firm supporter of coding conventions (at least of my coding conventions).
Software factories [^] [^] [^] and other code generation tools have been taking care of writing the tedious (and, sometimes, ugly) code but, at some point, some code must be written and read by human developers. That’s why (in my opinion) the way the code is written is as much important as the language it is written in.
There are several resources about coding conventions for the .NET framework:
I have to disagree with Microsoft’s position about naming conventions of private members. In an enterprise as big as Microsoft projects start and end, people move between teams and every time someone changes team he/she is faced with the possibility of having to learn and adapt to a new set of naming conventions for private members.
IDesign goes one step further on defining naming conventions for private members. I just don’t like the convention they used. What’s the point of prefixing private member fields (not variables as in their document) with m_? What does it mean? Member? If it’s not a local method variable or a method parameter it’s a member.
Some just prefix with _. Once again, why? What does that mean?
The only reason I can find for this prefixing practice is lost in the old days of colorless IDEs, printers and books. With colorful IDEs like Visual Studio 2005 you just need to qualify instance member fields with the this (Me for Visual Basic) keyword and static (Shared in Visual Basic) member fields with (lacking of a better solution) the class name.
Lets pretend for a moment that I’m one of the prefixes. How would I do it?
Why stop there? Let’s also prefix method variables:
Now I’m on a roll. Let’s prefix method parameters:
The next step would be to go Hungarian and add type information to the names, right? No. Let’s stop here and get in the right track.
I Find that keeping naming conventions as simple as possible is the best way use and validate them.
In my previous analysis mentioned two drwanbacks of this mocking framework:
Let’s start with the second one.
TypeMocks™ was the same tool for both the .NET 1.1 and the .NET 2.0 runtimes and they were avoiding the need to have two tools. But we already need two runtimes and two IDEs, so two versions of TypeMocks™ isn’t such an hassle. I’m glad they came to their senses about this.
Befere this new API, the usage of mocks was something like this:
Now, it’s more like this:
You’ll have to agree with me that the changes in lines 1 and 3 improve the reliability and readability of the test code.
The need for this one may not be obvious, so let’s look at an example.
Imagine we are testing this class:
As you can see, TestedClass uses ClassUsedByTestedClass:
Now, take these two tests:
These two tests will fail because the value of create in test one is wrong. To shield ourselves from this kind of mistakes, we can code the tests this way:
Now it’s clear that the wrong test is the first one. But I like to scope things using the using statement, so, this is a better looking solution.
I would be very happy with this last solution. But both these two solutions have have too much mocking infrastruture coded in the test code and, because the people at TypeMocks™ aren’t in the market of just making me happy, they came up with a better solution (available on Professional and Enterprise Editions only):
And do you know what they called this? Best Practices Patterns.
TypeMocks™ is more than just a mocking framework, and it now enables writing custom test decorators. These are test framework agnostic and it is simple to add more features to your tests. Now you can write your own version of VerifyMocksAttribute and ClearMocksAttribute (available on Enterprise Edidion only).
It’s now possible to mock internal interfaces in signed assemblies.
It is now possible to create return values within the recording block, saving even more time and having an easier flow.
Before you had to do this:
Now you can just do this:
There’s also a ReturnDefaultImplementation method in the RecordExpectations class that returns a mock that has default behavior.
.. and several other enhancements and bug fixes.