The Single Responsibility Principle of source control

No comments

Friday, September 18, 2009

The first design principle in SOLID is the single responsibility principle (SRP) that states that each object should have only one responsibility. Today I’ve found another place in which SRP is just as important – source control commits (check-ins).

Just like the programming principle the SRP of source control means that each commit should have only one reason. I’ve seen developers accumulate changes for various reasons. Some think that each commit should add considerable value to the project while others prefer to keep the code until “all of the loose ends are tied”. From

I think that hording changes doesn’t help the project or its quality instead it can only lead to opposite result.

When keeping changes on the development machine instead of the source control one of the following will happen:

  • When a bug is found - it’s hard to discover what change created it
  • Your code is not run part of the project until you commit it
  • You’re more likely to need to merge your changes on commit
  • Code reviews take longer… much longer
  • And last but not least - if your machine dies your changes dies with it

When a bug is found - it’s hard to discover what change created it

How many times have you received a bug report claiming that a feature that used to work until version x has stopped working? One way to try and understand why the bug occurs is to find out when the bug was introduced to the code. Doing a quick “binary search” to find the exact commit that caused the code to misbehave should be strait forward but once the offending revision is found wouldn’t it be great if it contained less than half of your project’s files?

Nothing is more frustrating from going over several hundred lines of diff’ed code to try and understand what change is responsible for the new issue.

Your code is not run part of the project until you commit it

If the project has a bunch of tests that are being run each commit (I hope for your sake it does) you definitely want your code and your tests to run as part of the build process. Even if no automatic build process exists you definitely want other developers to have your code as soon as possible, because otherwise they might write code that will cause your unchecked changes to stop working and won’t even realize it.

You’re more likely to need to merge your changes on commit

This scenario depends on the source control you’re using: Developer X and developer Y both developers change the same class. Because developer X commits his changes first developer Y needs to perform a merge of the new changes and his code. Sometimes it’s easy sometimes it’s frustrating and almost always annoying.

The longer you’re going to keep the code on your machine and the more lines of code that a commit updates the more likely it is that you’ll need to merge your code with code that was not there when you’ve started working on it.

Code reviews take longer… much longer

Code review is an excellent practice that helps the team grow together and share knowledge. The math is simple a code review takes an amount of time proportional to the amount of code being reviewed. A review of a specific change would take less time then a review of several non related changes.

Nothing is more discouraging when reviewing some else's code than to start a review on one feature only to jump to another and then to a bug fixed done on the way. Instead change only specific feature, review the change, commit it and than fix an unrelated bug.

If your machine dies your changes dies with it

I’ve once lost days of work because my development machine hard drive has stopped working and I didn’t commit the changes to the source control. Remember that the source control is a backup of your code and if you don’t backup your work you might loose it. I try not to have more then one day’s work between my commits to the source control mostly because I’m confident that I can remember what I did yesterday. When I get to the end of the day and I didn’t commit any code I look for the closest point in my current work I can commit so I would not face the risk of loosing my work.


There is no cost of committing your code whenever needed, my rule of the thumb is to check-in my code whenever I’ve finished writing code that improves the project and doesn’t break existing functionality (no failing tests).

There is no point of accumulating changes until some sort of “critical mass” is achieved. If you can put it back in the source control – you probably should.

Webinar - Successful unit testing from day one

No comments

Thursday, September 17, 2009

Writing unit tests can be harder then it seems, during my work at Typemock I’ve encountered developers that were frustrated and discouraged because TDD and unit testing didn’t seem to work for them. That is why we’ve decided to host a webinar about how to start unit testing your code.

I will be co-hosting this webinar with Gil and we’re going to talk about the tools, best practices and what should be avoided when writing tests.

We’re going to have two sessions:

8am GMT – 

2pm EDT -

So if you’re want to start unit testing and want to learn more about how it’s done join us in the upcoming Tuesday.

Concurrent podcast

No comments

Tuesday, September 15, 2009

I’m always on the lookup for new podcasts to listen to on my way to work. Yesterday I’ve found the podcast I was looking for ever since I’ve started writing real code – Concurrent Podcast.

This is the podcast about threading, locks, concurrency and the issues that they cause.

Currently two chapters has been posted:


If you want to learn more about multi–threading, synchronization and concurrency topics – you defiantly want to hear this podcast.

Software news – September 2009

No comments

Tuesday, September 08, 2009

Just a brief post to let you know of two cool tools being ready for their official release.

CppDepend goes RTM

I’ve just told you about nDepend in my last blog post and yesterday I’ve found that there is a tool in development that will provide the same functionality where it’s very needed – in the C++ world. This tool is amazing – from my experience writing a .NET analysis application is hard but writing the same kind of application to the native/unmanaged world is harder.image

Yesterday CppDepend RTM was just announced yesterday and it looks very promising. You can read the release announcement here, the tool is available for download from here.

SharpDevelop 3.1 Release Candidate 2 image

I’m a fan of #Develop, it is a great IDE and I wrote about it more then once

I’m excited about the upcoming release that will add never seen before IronPython support as well as other goodies – like the new profiler. The latest release candidate is available in the project’s site.

nDepend Review

No comments

Monday, September 07, 2009

There comes a time in every single “real world” project when its codebase becomes hard to manage, methods become too long, classes too complex and objects tightly coupled until it’s hard to tell where a functionality starts and where it ends. This is exactly the problem that nDepend is trying to solve. By putting all needed information at your fingertips it gives back the control to the project manager, architect and/or developer.

I’ve been using nDepend on and off since it was first created as a fledgling open source project that used to create an easy to understand call graph that I’ve used to understand how my code was called and what were its dependencies.

fast forward a few years and now nDepend still shows the same wellknown graph but packs a few (read: a lot) other features as well.

Running nDepend

Running nDepend is easy – just choose a project and pressing run.

To fully utilize all of this tool capabilities you want to learn a bit more about this tool. Luckily the good people that created nDepend supply tutorials and movies that teach all there is to know about this tool.

After the initial run a brief html report is created, the report includes the good old dependency graph as well as various data about the analyzed project (number of assemblies, number of properties etc.) and in case found – a list of warnings.

The warnings are where this tool shines, it comes with a bunch of predefined constraints:

  • Method has too many lines of code
  • High code complexity
  • Code is heavily commented – finally someone seen the light
  • And more, much more…

and if you need to add checks of your own – for example if you need to check that all classes have at least one non-static method, nDepend has a special query language that enables writing these custom queries called CQL, it’s easy to read and write and can be used to create new checks to make sure that a software project does not misbehave.

After browsing the report we can take a look the the main program screen. As you can see from the picture below this program needs as much screen real estate as you can give it (I had to close several windows to take this screenshot).


There’s code browser and graph and metrics and calls between assemblies and data as far as the eye can see…

Comparing Revisions

But that’s not all. During the last month I’ve been away from the internet (and work) for two weeks, I was able to use nDepend to compare the project as it was before I left to the state it was when I came back in a matter of minuets. In fact since I’ve discovered this feature I begun to use it to review the changes between Isolator released to check if the overall quality of code increased or decreased and why.


Although nDepend is not a “must have” development tool I can’t start to imagine how could a development lead or architect of a .NET enterprise application begin to understand what is going in his project without it.

Small projects would also benefit if its developers would have access to nDepend results (via build server) so they can see how each commit impacts the code.

But don’t take my word for it, download the fully featured (time limited) evaluation and see for yourself.

Related Posts Plugin for WordPress, Blogger...