One of your goals as a developer should be to make your code as readable as possible, both for yourself, and for the other developers you work with.

One great way to determine if your code is well written, is to ask yourself if the code you’re writing is readable by itself. Another developer should be able to jump into a module, and have a fairly easy time seeing what’s going on. They shouldn’t have to sift through thousands of lines of interweaved code to figure out what’s going on.

Of course, what I’m talking about is simply a test for the single responsibility principle. If you’ve written a huge "do it all" class with thousands of lines of code, you’re ensuring that you’re the only one that will be able to maintain it. That that type of code usually suffers from high coupling to the other modules in the program.

I used to organize code into classes based on the type of functionality being provided. I used them more as containers for related functionality. At the time, I didn’t see a reason to split it apart. I was very wrong.

In a recent article by Jimmy Bogard, he walks through creating classes with a separation of concerns. In the conclusion is my favorite part:

Now we have many more classes (4 vs. 1) and interfaces (3 vs. 0).  For those who don’t like more classes, GET OVER IT.

That is an excellent point. Why should you be afraid of creating more classes and interfaces? It’s really not more code to write, in fact, it’s often less. Refactoring tools remove many of the obstacles of maintaining the interface, class, and method structure

When someone looks at your code and you have 4 classes instead of 1, and those classes are very specific and short enough to process by our tiny brains, it will be much easier to maintain and modify (or even better, extend).

I’ve been really trying to use the Single Responsibility Pattern in all of the classes I design. Recently, I needed to create code to query a list of holidays from the database, and then create a method that allows you to get the number of holidays between two given dates.

Here was my first stab at the constructor:

public HolidayCalculator(IEnumerable<DateTime> holidays)

It’s simple and easy to understand. Then I started thinking about some of the dependency injected examples I’ve seen. For example, one of the Spring.NET IoC quickstarts has a similar example, except that they’re trying to list movies. In their example, they use an IMovieFinder interface. That interface has a single method that retrieves a list of movies. Using this concept, my constructor would look like (and what I ultimately changed it to):

public HolidayCalculator(IHolidayRepository holidayRepository)

That example originally seemed unnecessarily complex to me. Why separate something so simple and disconnected into an interface? Well, it turns out there are a couple of good reasons that you might want to do this.

Delay loading

With my original constructor, I had to load all of the holidays from the repository (ultimately a database in the production environment) to even create an instance of this class. This is certainly less than ideal when I want to use this class as a singleton that may get created early in the application.

Single Responsibility

In my original design, I was accepting in a list that would get cached in my holiday calculator. My class now has two responsibilities. It has to calculate holidays, and it has to cache the holiday list. What if I wanted to change how the list was cached? I would have to change the class, which is not ideal.

Ideally, this class would load the holiday list each time it needs to perform a calculation. The implementation passed into the constructor would be responsible for caching. In fact, we can now easily separate out the caching feature, and the holiday loading feature. Both classes would implement the IHolidayRepository interface and would be chained together. The caching class would take an IHolidayRepository.

Incremental Coding

Following the Agile philosophy, I can now deliver code faster. I don’t need to add a caching layer. I can have a working application in less time, and then later evaluate if I need to cache the holiday data.

Conclusion

Overall, this design is a little more work, but I think the benefits outweigh the extra classes and interface I needed to create. This design makes it easy to test, and each class has almost no code in it. Reading it and understanding it is extremely simple.

I’ve read books about what makes employees happy. If you manage people, I recommend reading the book First, Break all the rules - What the world’s greatest managers do differently. In that book, they surveyed tends of thousands of the best managers and employees. In their extensive research, they were able to come up with the 12 most important factors that make employees happy, increase productivity, and decrease turn-over.

1. Do I know what is expected of me at work?
2. Do I have the materials and equipment I need to do my work right?
3. At work, do I have the opportunity to do what I do best every day?
4. In the last seven days, have I received recognition or praise for good work?
5. Does my supervisor, or someone at work, seem to care about me as a person?
6. Is there someone at work who encourages my development?
7. At work, do my opinions seem to count?
8. Does the mission/purpose of my company make me feel like my work is important?
9. Are my co-workers committed to doing quality work?
10. Do I have a best friend at work?
11. In the last six months, have I talked with someone about my progress?
12. At work, have I had the opportunities to learn and grow?

A major point of the book is that managers are able to read employees, and treat each of them in a way that makes them happy and productive. That may mean that one person gets 5 monitors, and another gets an Optimus keyboard. Another employee may have to move into the basement, and give up their red stapler.

My opinion is that managers work for their employees. It’s the managers job to make sure the employees are productive, and to provide the right environment. If they can’t do that, they shouldn’t be a manager.

Lately, I’ve began wondering why managers don’t ask each employee this simple question:

"What do you need from me?"

If you’re manager doesn’t ask this, are they just guessing? In some cases the answers may not be incredibly useful, but in most cases you could learn a lot from the answer. For example, someone might say they need it to be quiet, and another might say they need a lot of background noise. A person might say that they need flexible hours or more desk space.

If you don’t ask that question, you may never know the answer. If you’re lucky, you’ll eventually be able to figure it out, but can you afford to take that chance?

If your manager doesn’t ask this question, why don’t you answer it anyway? Even if it doesn’t help your manager, it will certainly help you understand what you need to accomplish your goals. You may be able to find more creative ways to help your manager understand what you need to get your job done.

You’ve probably already heard of the new "var" keyword that you can use to declare variables in your .NET code. I wanted to clear up some quick myths and give a quick overview of when it’s most valuable.

If you haven’t heard of it, you can now use this syntax:

var c = new Cat();

Instead of this:

Cat c = new Cat();

As Jeff Atwood mentioned, it’s a great way to avoid redundancy. It’s obvious that you’re creating a "Cat" object, why do you have to say it twice?

The most important thing to realize, is that it’s NOT a var like in JavaScript or other languages (DIM in VB). It really is 100% a "Cat" object, complete with intellisense. The generated IL would be no different than specifying the type when you declare it. It’s simply a compiler trick.

Another important thing to remember is that you the assignment must be combined with the declaration. If that wasn’t the case, readability would be very poor.

var myName = "Jason"; //Allowed
var yourName; //Not allowed
yourName = "Bob"; //Glad you can't do this

What are some really good examples of when it ideally should be used:

List<Dictionary<int, string>> customers = new List<Dictionary<int, string>>(); //Yuck!
var customers = new List<Dictionary<int, string>>(); //Yay!

OrderRepository orderRepo = (OrderRepository)ctx.GetObject("orderRepository"); //Yuck!
var orderRepo = (OrderRepository)ctx.GetObject("orderRepository"); //Yay!

string name = "Jason Young"; //Kinda yucky
var name = "Jason Young"; //Kinda better

As you can see, those examples have obvious redundancy. Using the "var" keyword increases readability, and makes it easier to change if needed.

There are certainly times when its use is questionable. In the following example, I’m calling a function that returns some data. Since I’m not explicitly defining the type that is being returned from that function, I have to do some digging to figure out the type being returned. In this case, you’ll have to define the correct way to handle it in your coding standards.

var data = GetData();

Another potential readability issue comes up in the following case. You might not want to use the "Circle" specific methods (Circle inherits from Shape).

Shape s = GetCircle(); //I see what you're doing
var s = GetCircle(); //Do you want a shape, or a circle?

Aside from a couple of decisions that need to be made in your organization, I think this is a great addition, and should make our lives as developers a little bit easier. It’s just another tool for our toolbelt. With great power comes great responsibility

In what little free time I have, I’ve been slowly working my way through the book "Agile Principles, Patterns, and Practices in C#" by Robert C. Martin. This is a GREAT book, and a real eye opener.

This book has shaped some of the fundamental ways that I look at software. Whenever I look at a problem now, I think about how I’m going to create the building blocks to solve that problem. As an example, MSDN magazine just had a great article about the opened-closed principle which actually discusses this book.

Sure, I used to have excellent test coverage and modularity, but this book has given me insight to take it to the next level. For example, following the single responsibility pattern is a concrete way of making your code more adaptable to change, and makes your code easier to maintain and understand.

The book even offers information about studies that have shown a correlation between how often working software is delivered, and the quality of the final product. When points are made, evidence is often provided to back it up. It’s difficult to argue with real numbers.

The book covers these areas:

• Agile principles, and the fourteen practices of Extreme Programming
• Spiking, splitting, velocity, and planning iterations and releases
• Test-driven development, test-first design, and acceptance testing
• Refactoring with unit testing
• Pair programming
• Agile design and design smells
• The five types of UML diagrams and how to use them effectively
• Object-oriented package design and design patterns
• How to put all of it together for a real-world project

If you haven’t read this book, I highly recommend it. I think just about everyone could get something out of it. Even if you’re not practicing or learning agile, the techniques themselves are still valuable.

On a personal note, I feel like I’m entering a completely new level of software development. I don’t know if I’ve just been unlucky, but I’ve never worked with a team that really understood and/or practiced these patterns and practices. They certainly didn’t teach this stuff in school.

I became curious as to the adoption rates of agile, and the rate of success that people are seeing. There is plenty of information that shows that the agile process is being used, and has been working well for lots of teams.