| Chris Skardon's profileChris SkardonBlogLists |  Tools  Help |
Chris SkardonThe thoughts of me. |
|||||||||||||
|
November, 2007 Moving Blogs...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! November, 2007 ArgumentException / ArgumentNullException argument order.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 ArgumentNullException("myArg"); OK, not lazy as such, but I've kind of realised adding the message isn't really needed, there's not a lot more I can add that the exception itself doesn't describe, and I reckon this is what was intended when it was designed - sure - you can add a message - but why bother? The ArgException does need the message, and it's far more important than the paramName argument because there are so many different reasons for the exception to be thrown - too long, too short, too many letter 'e's etc. By making the message the first argument, a developer (hopefully) thinks about what to write there, and a subsequent user of the class can get a good reason for the exception. So, now every time I get the args wrong (which - thanks to this revelation - happens little now) I apologise to the designers for my previous curses :) October, 2007 Build Errors: 399, Unit Test Failures: 187... Time to rethink?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 - to hell with it! - It's only been a day so far, why waste more?? Each of the decisions has it's pros and cons, option 1 will likely be a hard slog, but ultimately pleasing to finish. Option 2 might lead to a quicker, nicer implementation. Of course, option 2 might also lead to you having to redo the work - which is why before rolling back it's worth copying the folder with your current changes in to another folder, so you can just go back to it as soon as you like / need. Each decision is based on the current scenario, there will be cases where doing option 1 is right, and where doing option 2 is right, and I think being a good developer is being able to figure out which of the two you should choose. October, 2007 Code smelly??? Well... yes, yes it is...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 the senior developer gets an opportunity to get the code changed, and the junior developer learns and progresses (hopefully). Code reviews can also allow the senior developer to learn from the junior developer. Quite often (in my experience) I had kept much more up to date with new technologies and framework (.NET) internals, meaning I used bits of the framework, or tools, which the senior dev didn't know about. The benefit the junior developer gets from this role-reversal is that the senior dev can reign in the junior, and actually get a product out, rather than constantly in a loop of newer and newer technologies being deployed. Personally, I agree, Code Reviews do have limitations, and in general they're best for reviews of how the code is implemented, (using StringBuilder rather than string concatenation for example). They can make everyone (in the team's) code much more inline with each other, and that can only be a good thing! September, 2007 Source Control!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 merge). I recently encountered the deadlock situation above, rolled back my file, waited for the other developer to check-in his changes and then went to reapply mine - problem was - I'd forgotten what I'd done, I'd taken a copy of my original edited version, but suddenly realised - if I just check in my change - I'll just overwrite the other developers code - which led to a large amount of reading the history of the file to try to reapply his changes - to cut a long story short - not a good method! The Vault route allows you to just do your work, deadlock doesn't occur and this is exactly what we want. Both of us can have the code checked out and the last one checking in has to do a merge. The automatic merge tools are brilliant these days, and if they can't do it, then manual is the way - again, good tools can help this immensely. Vault is the only program I've used to do this and I can't help but praise it, if I ever (again :)) make the source control decision, I'll be heading straight to Vault! With the advantages there, why don't more people do the edit/merge/commit source control? Fear seems to be one of the biggest stoppers - questions always arise: What about merging? That *always* goes wrong! To be fair, SourceSafe hasn't made merging easy, and I have yet to use CVS etc so I can't comment on those tools, but having a good tool makes this just not a problem. |
||||||||||||
Send a private message
Subscribe to RSS feed
Tell a friend
Add to My MSN
Add to your network
Sign up for alerts
|
|
