My MSN

Click OK to add this content

 
Content Preview: rss
-+Moving Blogs...
738 days ago
I've taken the unilateral decision to move to a different blog server - so I can use tags and more than one category etc. So --- the new blog location is: http://www.xclave.co.uk/ Hope to see you there my one reader!
-+ArgumentException / ArgumentNullException argument order.
758 days ago
When I come to use the ArgumentException or ArgumentNullException I pretty much always get the argument order the wrong way around - is it 'paramName' first, or the 'message'? Every time I do this I silently curse the framework designers and swear I would have made the args the same way around, either 'paramName' first always, or the message first. Then, not 10 minutes ago, I finally twigged why. Or at least a reason why... Typically (at least in my code) the exceptions are used in the following manner: public void Foo(string myArg) {     if(myArg == null)        throw new ArgumentNullException("myArg", "Argh! You simply *cannot* use a null string here!!");     if(myArg.Length == 0)        throw new ArgumentException("Empty strings just don't make sense!!", "myArg");     /* Other Stuff Here */ } But recently I've been being a bit lazy with my ArgNull exceptions; throw new ...
-+Build Errors: 399, Unit Test Failures: 187... Time to rethink?
773 days ago
Being a software developer is all about writing code right, right?? But what about deleting code? At what point should a developer make the hard (and it is hard) decision to rollback that afternoon's / day's / week's work. Plugging away for a long time is something I would have thought a lot of developers were familiar with, and it's tempting to just keep on going, destroying the developer soul inside you and becoming what is known as a 'cynical developer' - or - 'senior developer'. ;) We've all been in the situation where you implement a new piece of code and it (seemingly) breaks every single piece of code that exists in the company, you do a quick 'build' check, and get only 23 errors, not bad eh? Fix them, get down to the last one - fix that - build, gah! 399 errors ?!?! Where the f*ck did they come from? What to do??? Well - what are the options? 1. Continue on the route to success. - The design must be right, you will succeed!!! 2. Rollback / rethink - ...
-+Code smelly??? Well... yes, yes it is...
791 days ago
There I was reading an ex-colleagues blog site, and came across a recent article about the downside of Code-Reviews, and why they don't work. But this got me thinking, why does he frown on the code review process? I used it in my last position to great effect. I found it provided a fantastic support role for less experienced developers (like myself) and for the senior developer at the same time. The major benefit to the senior developer has to be getting the code changed. It's very easy to sit there talking to your peer developer essentially bad-mouthing the inexperienced developer's code, particularly if all you do is look at it, swear at it and then don't bother mentioning it to the inexperienced dev ( I fear I'm guilty of doing this on many occasions ). The code review process allows the senior developer to first ask why code was written a given way, and secondly suggest better (?) ways of achieving the same goals. The benefit here is that ...
-+Source Control!
810 days ago
I've worked on two different source control methodologies in my brief software career, the SourceSafe exclusive checkout way, and the Vault - edit, merge, commit route. I've used three applications, Microsoft SourceSafe 6.0, SourceGear Vault (3.5) and currently Microsoft SourceSafe 2005. They methodologies both have their benefits, clearly the SourceSafe way gives security, you know no-one else is going to be editing your code, and there will be no horrible merge when you check-in. But the major (and personally I think it's a deal-breaker) drawback is that when working in a team of developers you can very easily get into a deadlock situation where developer A needs access to FileB (which developer B has checked out) and developer B needs access to FileA (which developer A has checked out). The usual result of this situation is an 'undo check-out' by one of the developers, or them going 'renegade' and disconnecting from the source control (which will result in a ...
© 2009 MicrosoftMicrosoft