A collection of links

Once again I’ve been too busy to comment on the following blog postings in a timely manner so here’s a collection of stuff that’s been sitting in my “good stuff” list for a while now.

Josh Carter over at “multipart-mixed” warns us of “The Perils of Bad C/C++” Schools. I must admit that I agree with him here, far too many programmers that I’ve dealt with over the years don’t really understand pointers even though you would think, from their background, that they should. Too often these guys will fix pointer “issues” with, seemingly, random insertions of *’s and &’s until the code “works”, that is, of course, compiles… I’ve never really had a problem with pointers, but then I taught myself to program and one of the first things I did was write a wrapper for memory management so that I could track leaks in my programs (this was back in the dark days of DOS when I couldn’t have afforded special memory leak tracking tools even if they were available to me) . Once you’ve wrapped memory allocation functions and allocated extra memory to hold allocation trivia and sentinel bytes and generally frigged around with the block of memory that is being requested you get a pretty good feel for how pointers work. In fact I used the same trick to get a new graduate up to speed on pointers once; the difference being I used my memory management wrappers for years whereas his work was just so that he’d fully grok pointers and was destined for the bin not that he knew that at the time). I’ve always found that just drawing boxes and lines tends to help explain pointers and I find that I still draw such diagrams when I’m working with more complex pointer designs (well, actually I’m always scribbling some form of boxes and lines diagram).

Scot Berkun lists some interesting exceptions to Brooks’s Law all of which seem like sensible things. It’s still worth making sure that your management has read The Mythical Man Month and, more importantly, understood its lessons, before allowing such flexibility ;)

And speaking of The Mythical Man Month… There’s an interview with Fred Brooks over at Fortune magazine.

Brad Abrams has some sensible stuff to say about exceptions. He’s talking from a .Net perspective but what he says is applicable to all exceptions use.

Jeff Darcy over at “Canned Platypus” talks about Code Reviews. The comments are worth reading, especially the one from Steven F. LeBrun who suggests that informal reviews are more effective than the big stuffy formal style of code review. That’s pretty much my view, and, to be honest, pair programming tends to act as a constant review anyway… I especially like his comment on “special pleading”, too often I see “but we’re different because” used as an excuse to avoid things that people are too lazy to do and now I have a great phrase to use before I force them to “show me the code and how your special situation makes it good!”.

Jeremy D. Miller over at “The Shade Tree Developer” is writing a series of articles about mock objects. They’re well worth reading. You can jump into the series here; it’s sensible stuff and well worth reading, as always.

Peter Ibbotson gives us his take on LINQ after attending a talk on the subject by Ian Griffiths. I share Peter’s reservations about embedding SQL in the wrong place. Yeah it’s sexy and cool (and useful!) to be able to embed complex data access into your mainline C# code but does it encourage good design? I’d prefer to see my data access code in a single place, accessed via an interface so that I can mock it up when needed. Once you have LINQ style data access code spread throughout your codebase you may find unit testing harder… Sometimes hard things should stay hard ;)

Steve Pavlina talks about how to Raise Your Standards. An interesting, non techie, piece that can easily be applied to how you code.

Tim Anderson writes about DLL hell Visual Studio 2005 style. This is why I tend to favour static linking. I notice that Tim mentions that Microsoft encourage you to dynamically link the CRT for ‘security’ reasons, yet surely, if you have to embed a manifest that ties your app to a particular version of the CRT dll then your app wont “automatically” take advantage of a new CRT with security fixes…